Bug #4700

[Workbench] Websocket client should only subscribe to events about relevant objects, not all events.

Added by Tom Clegg over 4 years ago. Updated over 4 years ago.

Status:
New
Priority:
Normal
Assigned To:
-
Category:
Workbench
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Story points:
2.0

Description

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.

History

#1 Updated by Tom Clegg over 4 years ago

  • Description updated (diff)
  • Category set to Workbench

Also available in: Atom PDF