On 17 November 2011 15:28, Ken Giusti <[email protected]> wrote: > Hi Rob, thanks for the info - very helpful. I'll write up a more formal > description of the proposed functionality shortly - give us something a > little more tangible to review. > > One question specific to the Java broker's behavior - an edge-case I'm > trying to wrap my head around: > > With selectors, I'm planning on associating a current position with each > consumer - just as you described below. This is somewhat new to the C++ > broker, as currently all consumers consume from the queue's head. A > position attribute adds a new wrinkle to the broker's handling of released > messages: > > Does the Java broker reset/rewind a consumer's position when an acquired > message is released back to the queue? For example, assume a queue with > multiple subscribers consuming from it in parallel, with the potential that > their selector match criteria overlaps. If a consumer acquires a message, > then at some later point releases it, does the Java broker 'back up' the > other consumers that may have skipped over that message due to it being > acquired? >
Essentially, yes - when a message is released into the queue we iterate over the subscriptions to ensure that none of them is "ahead" of where the released message has been returned to. There are a number of wrinkles in the Java code here due to the way we implement the queues. It gets even more hairy where your queue ordering is not strictly FIFO (for Priority Queues, or the Sorted Queue implementation that we've also developed). -- Rob
