[concurrency-interest] PriorityBlockingQueue question

[David Walend]

Begin forwarded message:

> From: David Walend <david at walend.net>
> Date: September 27, 2006 8:57:56 AM EDT
> To: Tim Peierls <tim at peierls.net>
> Subject: Re: [concurrency-interest] PriorityBlockingQueue question
>
> On Sep 26, 2006, at 11:11 AM, Tim Peierls wrote:
>
>> On 9/26/06, Tim Peierls <tim at peierls.net> 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.
>
> Dave
>
> David Walend
> david at walend.net
>
>

David Walend
david at walend.net