Attribute Events gets missed

Hi Andy,

Andy
are you using Java to implement your device server? In this case the issue #424 Reynald is working on is not going to help because it is only for C++.
Yes we are using Java to implement device server.


Andy
n order to quantify the event loss can you try with only a few attributes and then increase the number until you start losing events. Have you tried splitting the attributes across multiple device servers? Does it still happen? Is there anything in the logs?
We will try this and let you know the results/observations
Regards,
TCS_GMRT
Hi,

I think we still need more details.
What is the data type of the attributes for which you are missing events? Spectrum attributes? DevDouble, DevFloat, DevState, DevBoolean…?
What are your clients? Atkpanels? Java clients? C++ clients?

Are the clients subscribing to change events only or also to periodic events?

You were writing your commands are not taking a long time to execute, less than 3 seconds.
If a command is taking 2 seconds to execute, this means that during all this time, no attribute can be read because there is a locking mechanism in Tango which by default makes it impossible to read an attribute in parallel of executing a command or reading another attribute. This is to simplify the device server programmer's life and make thread-safe device servers.
So 2 seconds command execution for instance would be a very long execution time in your case if you want to be able to poll your attributes at 200 ms, or even 10 ms!
So please check your commands execution times and ensure they are not the cause for event losses.

If your attribute is a number scalar/spectrum or image attribute (types DevDouble, DevFloat, Dev(U)Short, Dev(U)Long(64), DevUChar), you need to specify an absolute change or relative change threshold configuration, unless you manually push events by code without checking the thresholds, otherwise you should get errors during the subscriptions (Example for a C++ device server):

Error reason = API_EventPropertiesNotSet
Desc : Event properties (abs_change or rel_change) for attribute devfloatspectrumro are not set
Origin : DServer::event_subscription

If you are using a generic client like atkpanel, I think it tries to subscribe to change events by default and if this fails, it will subscribe to periodic events. If you didn't change the period configuration parameter of the periodic event for the attribute you are subscribing to, you will get the default period value, which is 1 second.
So, if you subscribe to a number attribute with a generic client like atkpanel and did not specify the absolute change or relative threshold, you will end up with an event received every 1 second, even if you specified a polling period below 1 second.
In atkpanel, you can identify that easily by clicking on "View->Diagnostics…" in the menu, and then choosing the Attribute tab. You will see if ATK is receiving events for your attribute, and also what kind of event (Change event, Periodic event).
You can use the "Update fields" button at the bottom of this ATK diagnostic window to refresh the values.

Hoping this helps,

Kind regards,
Reynald
Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.
Edited 1 week ago
TCS_GMRT
Reynald
Maybe the server is not sending events because the conditions are not met (the attribute value didn't change enough to send an event)?
Could you please verify that?

Attribute values are getting changed surely. (any change in spectrum attribute value should send an event)

Just for clarity, in addition to Reynald reply, any change in spectrum attribute value should send an event *provided* you specified the event (change, archive) thresholds in the Attribute event configuration. If not, no event will be sent, and you should get an exception when subscribing…
Edited 1 week ago
 
Register or login to create to post a reply.