Re: monitors received out of order

[Ralph Lange <Ralph.Lange@bessy.de>]

 On 03.11.2010 05:17, nick.rees@diamond.ac.uk 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