> From: David Walend <[hidden email]>
> Date: September 27, 2006 8:57:56 AM EDT
> To: Tim Peierls <[hidden email]>
> Subject: Re: [concurrency-interest] PriorityBlockingQueue question
> On Sep 26, 2006, at 11:11 AM, Tim Peierls wrote:
>> On 9/26/06, Tim Peierls <[hidden email]> wrote:
>> No ideas for this -- I'm thinking about the other approach.
>> What if you maintained a separate queue for each selector and
>> atomically marked messages when consumed? (You could use
>> AtomicMarkableReference.attemptMark, for example.) Then you don't
>> have the problem of having to remove a message from all other
>> queues, since receivers can simply ignore messages that someone
>> else marked.
>> Then take(selector) is just "take from queue associated with
>> selector" -- more precisely, repeatedly take until you can
>> atomically mark an unmarked message. I think you could use PBQs
>> instead of PQs and a ConcurrentMap from selector to queue,
>> avoiding the need for a global lock.
> Thanks, Tim. That sounds much better. I wouldn't (and didn't) find
> AtomicMarkableReference on my own. Also, everything that can have a
> message selector also has a close() method that I can use to drop
> the PBQs when nothing is listening.
> I like the approach. It promises to be very lively, but will make a
> lot of AtomicMarkableReferences to GC.
>> Not sure of the desired behavior for messages that don't match any
>> currently waiting selector. Are they discarded? Left in their own
>> queue for selector-less consumption? Or do they have to be scanned
>> for matches each time you hear about a new selector? (In which
>> case it might seem as though you're almost back to the other
>> approach, but maybe without the need for a global lock.)
> That one is pretty straight forward; the Channel has to have a king
> PBQ that represents the JMS Queue's contents (for QueueBrowsers if
> nothing else). When something adds a new message selector, the
> Channel will have to get a copy of that PBQ's contents into the new
> message selector queue. Then it should be off and running. It's OK
> if up a new QueueReceiver is relatively heavy.
> Thanks again for the help. I hope to code it up over the weekend.
> David Walend
> [hidden email] >