Bug #4700
Updated by Tom Clegg over 9 years ago
Currently, Workbench subscribes to all events. This means it receives every log message from every (readable) job that is running -- even when viewing the pipeline_templates#show page where none of those log messages will ever result in a visible change. This can cause excessive resource use, for example, when an administrator has a few Workbench tabs open while a user is running jobs with chatty stderr or making updates to collections with large manifest_text.
Ways to improve:
* Use filter @['object_uuid','in',uuids]@ where uuids are the ones mentioned in data-object-uuid attributes.
* Use filter @['event_type','=','update']@ when there is no @.arv-log-event-listener@ on the page. (Rather than special-case this, each listening element could provide a space-delimited @data-listen-to-event-types@ attribute, e.g., "update" for most listeners, and "update stdout stderr" for the log viewer.)
Implementation notes:
* Make sure the list of interesting uuids gets updated in/after the @.arv-log-event-subscribe-to-pipeline-job-uuids@ handler in pipeline_instances.js.
* The websocket service has a hard limit (not discoverable in advance, but currently 16) on the number of active filters in use by a single connection. To avoid hitting this limit, Workbench could do "subscribe {new filters}; unsubscribe {old filters}" each time its selection criteria change.