Skip to content

New event subscribtion mechanism

Antoine Dupre requested to merge AntoineDupre/web-maxiv-tangogql:aioattribute into develop

This PR propose a new way of managing event subscription.

Current status

Today, the "event subscription" in tangogql is not using the pytango event system. When a client ask to get data through the web socket, a recursive coroutine send to the web socket every 3 seconds to one client. If two clients ask the same data, two different coroutines are going to poll the same attributes. All the attribute for a client are updated at the same time.

What's new

This PR propose to implement some tango event subscription mechanism like Taurus do:

  • subscribe to change event if possible
  • if it fails, subscribe to periodic event channel
  • if it fails, poll the attribute

Also, each attribute are polled/subscribed only one time. If two clients ask the same attribute each time a new tango event is received (or on polling ticked) both client will be notified.

Drawback

On change event subscribtion, if the tango event filters are activated, and the value is not updating, no new value will be send to the websocket. To be clear when the event happended, webjive shall probably use in trends the tango timestamp on the x axis (instead of counting time).

Improvement

  • There is nothing right now that inform the client of tango errors
  • Now each attribute can have it's own polling rate, maybe something between webjive and tangogql can be implemented to configure the polling rate.
  • On change event subscribtion, it can be valuable to add an heart beat system or a extra slow polling mechanism to notify the client and read the attribute even if no change happened
  • Event subscription is synchronous because tango is not able to deal with concurrent zmq subscription https://github.com/tango-controls/pytango/issues/307
Edited by Antoine Dupre

Merge request reports