Forwarded events sometimes contain the previous attribute value

[bourtemb]

Let's suppose we have a Java device server with a forwarded attribute pointing to a string root attribute exported by a C++ device server.

When the C++ device server is pushing events for the root attribute, the clients having subscribed to the forwarded attribute might receive events containing the previous value of the attribute instead of the current one.

This problem is due to the combination of 2 factors:

• The C++ device servers polling thread is pushing events before filling the polling buffer with the new value (It might be the same in Java device servers, I don't know yet). This sounds reasonable because we want the clients to be notified as soon as possible.

• If I understood well the source code, the Java device server, when receiving an event from the root attribute, is ignoring the attribute value contained in the received event, and is doing a synchronous read of the root attribute before pushing an event with this value. This synchronous read will return the latest value from the polling buffer. And sometimes, the polling buffer didn't have enough time to get updated with the latest value.

I think the Java device server should simply forward the attribute value it received in the event coming from the root attribute instead of doing a synchronous read of the root attribute in this case.

[Ingvord]

@bourtemb thanks for the detailed report!

The C++ device servers polling thread is pushing events before filling the polling buffer with the new value (It might be the same in Java device servers, I don't know yet). This sounds reasonable because we want the clients to be notified as soon as possible.

Sounds like a poor design to me. I would suggest the following architecture: polling threads fills in buffer and notifies worker thread (pool) that sends a notification to the clients taking value from the buffer. This way we do not block polling thread for doing IO + notification is being send immediately for the clients perspective. Finally this is a common pattern widely used. I will implement this in Java (if not yet done by @gwen-soleil ) to see how it performs.

I think the Java device server should simply forward the attribute value it received in the event coming from the root attribute instead of doing a synchronous read of the root attribute in this case.

+1

[bourtemb]

When I tested this with a Java client subscribing to a forwarded attribute provided by a ForwardedComposer device with a root attribute pointing to a tango 9.2.5a C++ device attribute (from TangoTest device server for instance), I saw the client was receiving some heartbeat errors with the current version. It was not the case with the previous version.

[gwen-soleil]

@bourtemb is it still not working with JTango-9.5.11 ?

[bourtemb]

I tried with a ForwardedComposer device server in JTango-9.5.13 with a root attribute pointing to a C++ or Java device server attribute. In both cases, when a client subscribes to change events for the Forwarded attribute, I receive 2 events every time the value is changed (only 1 event is received during the subscription phase).

I get only one event per change if the server is using JTango-9.5.8.

I experience some heartbeat issues with Tango 9.2.5 C++ clients subscribing to the forwarded attribute when the ForwardedComposer device server is running on a host having multiple network interfaces. No hearbeat issue when the device server uses JTango-9.5.8 on the same host or when using a Tango 9.3.3rc C++ client.

[Ingvord]

I experience some heartbeat issues with Tango 9.2.5 C++ clients subscribing to the forwarded attribute when the ForwardedComposer device server is running on a host having multiple network interfaces. No hearbeat issue when the device server uses JTango-9.5.8 on the same host or when using a Tango 9.3.3rc C++ client.

I think this is also related to the issue I have in rest-server: issue-182

[bourtemb]

This bug seems to be fixed in JTango 9.6.6. Thanks! Closing this issue.