Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <47B40DE4.4010403@nuix.com>
Date: Thu, 14 Feb 2008 20:46:12 +1100
From: David Sitsky <sits@nuix.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: dev@activemq.apache.org
Subject: Re: Question about Queue.removeSubscription()
References: <47B379A5.10906@nuix.com>
 <944F227A-0A58-4C25-9BF1-2B7D388E4FB5@gmail.com>
In-Reply-To: <944F227A-0A58-4C25-9BF1-2B7D388E4FB5@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

> The reason for redelivering messages when a subscription is removed is 
> because other subscriptions may have originally disocunted those 
> messages because they were locked when they came to try and dispatch them.

That's interesting... because with the current code these messages are 
left on the pending list.  What you say makes sense for a better 
implementation.

> The whole Queue dispatch model is not very scalable because each message 
> is being delivered to each subscription - this, I think was done because 
> it made the implementation of exclusive consumer easier.
> I'm currently moving away from this model - to decide at  Queue dispatch 
> time which subscription should get the message - just like a - well a 
> Queue!

I think that makes a lot of sense!  I want my application to scale to 32 
or 64 consumers hammering away, and with the current implementation, I 
can't see that happening.

It all sounds great Rob - any rough ideas when this might ready?  Let me 
know and I'll give it a good workout. :)

Cheers,
David