Mailing-List: contact activemq-dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Importance: normal
Priority: normal
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Pulling consumer design
Date: Thu, 10 Aug 2006 15:02:41 -0400
Message-ID: <CDDDC0C865D82541AE653837EA51A1B17AD0E9@NYWEXMB84.msad.ms.com>
In-Reply-To: <ec6e67fd0608101148l6d5a54c0y35e4e9ac5cf4d75e@mail.gmail.com>
Thread-Topic: Pulling consumer design
Thread-Index: Aca8rbuBCbRKCVBXQDen4R+GGz6RlQAASZtQ
From: "Pesochinskiy, Vadim \(MSCIBARRA\)" <Vadim.Pesochinskiy@mscibarra.com>
To: <activemq-dev@geronimo.apache.org>

Thanks a lot, this is great!!!

In the standard amq distribution there is this all-including jar called
incubator-activemq-4.0.1.jar.

I cannot make maven build this. I use the following command, which
creates all target jars but not the one I need.

mvn -Dmaven.test.skip=3Dtrue package


-----Original Message-----
From: James Strachan [mailto:james.strachan@gmail.com]=20
Sent: Thursday, August 10, 2006 11:49 AM
To: activemq-dev@geronimo.apache.org
Subject: Re: Pulling consumer design

On 8/10/06, Pesochinskiy, Vadim (MSCIBARRA)
<Vadim.Pesochinskiy@mscibarra.com> wrote:
> James,
>
> One way to implement this, which I think will fit with current design=20
> is to introduce a MessagePullCommand, which informs the broker that=20
> consumer is ready to accept next message. When broker get this request

> it dispatches one message to this consumer. What do you think about=20
> this?

Good idea. Actually if you check SVN trunk I committed something like
this about an hour ago :)

I'm just committing a test case that shows it working as I type
(ZeroPrefetchConsumerTest) :)

So basically prefetch of zero can be supported for synchronous consumers
(where receive(long) or receive() is called). We throw an exception if
you try and use it for async subscription
(consumer.setMessageListener()).

The one issue with the current implementation is that the
receive(timeout) must wait long enough for a message to arrive from the
broker; otherwise the method may return but a message is dispatched just
shortly afterwards. So provided you give a reasonably large
receive(timeout) then it should do what you need.

--=20

James
-------
http://radio.weblogs.com/0112098/
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender =
does not intend to waive confidentiality or privilege. Use of this email =
is prohibited when received in error.