Open crotwell opened 2 years ago
Actually, ringserver responds with Error parsing READ command parameters
which makes more sense. Bug in my script.
Still woudl be nice to have READ EARLEST.
Last comment, the reason for this idea...
You can fake it with POSITION EARLEST and then READ the returned packet id. However, in a busy ringserver with large data volume, the packet id returned might get flushed out of the ring before the read command can be sent. Hence a single op atomic READ EARLIEST and READ LATEST won't cause a race condition.
Hence a single op atomic READ EARLIEST and READ LATEST won't cause a race condition.
Being pedantic: It's only atomic from the client perspective, it remains a race condition in the server, which has code to check that the positioning of a read and then a subsequent actual read of the packet got the same thing. Granted this would reduce the "misses" significantly compared to the time incurred in the network command transit. It's just not perfect, because it's always possible to skip off the end of a very busy ring.
Fair enough. And on reflection I am not sure how useful this actually is, so feel free to "won't fix" this unless you think it has use.
The protocol supports
POSITION SET EARLIEST
but might also be useful for debugging to supportREAD EARLIEST
to get the earliest packet. And similar forREAD LATEST
.Ringserver currently responds to
READ EARLEST
with error ofPacket 0 not found in ring
which doesn't make it clear if this is not part of the protocol, or if is just not implemented in ringserver/libdali.