Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Wed, 03 Nov 2010 09:33:50 -0400

 On 03.11.2010 05:17, [email protected] wrote:

Yes, I agree with Till. Any mechanism which requires the client to
buffer a number of monitors for each subscription and then compare
timestamps is too difficult for the average client.

That's why such a thing should be handled in a library or a middle-layer
service. (See other mail.)
I am happy for the mechanism to break if the event queue overflows, but I
would like a client's event queue on the server to be a single
time-ordered FIFO queue, rather than a collection of queue's. However,
the details are probably a bit of a devil.

Such an implementation would have to use a linked list for the FIFO
event queue instead of a ring buffer. That way, there would only be one
queue per client (no chunking), and in case of overflow, the overwritten
element could easily be moved to the end of the queue.

In this design the order of the incoming updates (from the database)
would always be preserved through the event queue.
Which does *not* mean that the time stamps are in order, as
record/device support is free to set the time stamp of an update to
anything.

I think this would be adequate, though, as time ordering the event queue
on insert is an expensive operation. It would also open up a bunch of
issues with e.g. updates from records that use a device time stamp that
is 10 seconds in the past - these would always be inserted at the front
of the queue and delay (if not prevent) sending earlier updates from
other records with legal correct time stamps.
Why don't you file a wishlist bug on Launchpad for the issue? That could
actually make a nice Codeathon project.
Cheers,
Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System