qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Chase <adam.cha...@gmail.com>
Subject Re: Java atomic bindings Was: Re: Queue creation/deletion
Date Wed, 11 Feb 2009 19:24:10 GMT
I ended up trying what you propose.  I had an issue that I didn't know
when I could delete the queue.  I ended up sending messages back to
the producer to do the deletion which worked and then it all got very
slow when I added clustering.  My requirements have eased a little in
this area and I'm now pursuing a solution with a  small fixed set of
queues.

Adam

On Wed, Feb 11, 2009 at 1:34 PM, Gordon Sim <gsim@redhat.com> wrote:
> Adam Chase wrote:
>>
>> I am not totally seeing how I can use this to solve my problem.
>>
>> I am currently sending all my messages to a direct exchange with the
>> same routing key.  (Maybe a mistake).  Suppose I had each "group" of
>> messages have a different routing key.  I can't get all the messages
>> going to that exchange on a single queue, right?  And once a message
>> is routed to a queue, changing the binding wont re-route the messages,
>> right?
>>
>> What I want:
>> Producer: A1, B1, C1, D1, A2, B2, A3....
>>
>> Consumer:
>> A1 (asks for a few more As)
>>  A2, A3, A4
>> B1 (asks for a few more Bs)
>> etc.
>> etc.
>>
>> I can't create queues for each group because there are going to be way
>> too many (but the active set should be small).
>
> What is the issue with creating and deleting the queues as needed?
>
> E.g. producer creates a queue for all the A? messages (e.g called queue-a)
> then sends a message to main-queue with a reference to this queue, then
> sends A1, A2, A3 to that queue followed by a end-of-data message when all
> the A? messages are sent. Likewise for the B group etc
>
> The consumer then reads the initial message, then subscribes to the queue
> referred to, pulls all those messages off and when it gets to the
> end-of-data it cancels the subscription and deletes the queue.
>
> Would that work? If not is it a scalability concern over the churn of the
> temporary queues?
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message