STOMP redelivery policy

[Roger Hoover <ro...@gmail.com>]

Is there any way to configure maximumRedeliveries for a STOMP connection?

I ran tests against 5.2 and 4.1.1 and both redeliver the message
infinitely.  This causes consumers to keep choking over and over again on
the same message unless the consumers implement their own maxRetries logic.

It looks like this same issue has been brought up before (
http://www.nabble.com/Maximum-redeliveries-td17180816.html) but I'm
wondering if anything has changed since then (May '08).  For
ActiveMessaging, it looks like Andrew implemented his own max retry logic (
https://trac-git.assembla.com/breakout/browser/vendor/plugins/activemessaging/lib/activemessaging/adapters/stomp.rb?rev=a288646f5565a84e1358d827e889b13ea73abca4
)

Thanks,

Roger

Re: STOMP redelivery policy

[Roger Hoover <ro...@gmail.com>]

Hi Dave,

I don't have any information about ActiveMQ itself but in my own python
STOMP client, when an exception is thrown while processing a message, I have
the client enqueue a copy of the message on an error queue and ACK the
original message to the broker.  The gotcha you to watch out for when doing
is it to make sure you pass only the original "message-id" header.  It will
mask the new header that gets assigned by the broker to the message in the
error queue and you'll later get an error when you read from the error queue
and try to ACK that message.

HTH,

Roger

On Tue, May 5, 2009 at 8:45 AM, drsnyder <sp...@dsnyder.com> wrote:

>
> I did not see a response to this, but I am interested in this functionality
> as well...  if not supported directly by activemq, is it possible to use
> camel to do this?  What are others doing that want to implement the dead
> letter channel pattern doing?  Our consumer is python, so we are limited to
> stomp... I understand there may be openwire bindings as well but we would
> prefer stomp if possible.
>
> Any help, or even a "this is not possible", would be appreciated!
> Dave
>
> P.S. We are using activemq 5.2
>
>
> Roger Hoover wrote:
> >
> > Is there any way to configure maximumRedeliveries for a STOMP connection?
> >
> > I ran tests against 5.2 and 4.1.1 and both redeliver the message
> > infinitely.  This causes consumers to keep choking over and over again on
> > the same message unless the consumers implement their own maxRetries
> > logic.
> >
> > It looks like this same issue has been brought up before (
> > http://www.nabble.com/Maximum-redeliveries-td17180816.html) but I'm
> > wondering if anything has changed since then (May '08).  For
> > ActiveMessaging, it looks like Andrew implemented his own max retry logic
> > (
> >
> https://trac-git.assembla.com/breakout/browser/vendor/plugins/activemessaging/lib/activemessaging/adapters/stomp.rb?rev=a288646f5565a84e1358d827e889b13ea73abca4
> > )
> >
> > Thanks,
> >
> > Roger
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/STOMP-redelivery-policy-tp22141094p23390201.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>

Re: STOMP redelivery policy

[drsnyder <sp...@dsnyder.com>]

I did not see a response to this, but I am interested in this functionality
as well...  if not supported directly by activemq, is it possible to use
camel to do this?  What are others doing that want to implement the dead
letter channel pattern doing?  Our consumer is python, so we are limited to
stomp... I understand there may be openwire bindings as well but we would
prefer stomp if possible.

Any help, or even a "this is not possible", would be appreciated!
Dave

P.S. We are using activemq 5.2


Roger Hoover wrote:
> 
> Is there any way to configure maximumRedeliveries for a STOMP connection?
> 
> I ran tests against 5.2 and 4.1.1 and both redeliver the message
> infinitely.  This causes consumers to keep choking over and over again on
> the same message unless the consumers implement their own maxRetries
> logic.
> 
> It looks like this same issue has been brought up before (
> http://www.nabble.com/Maximum-redeliveries-td17180816.html) but I'm
> wondering if anything has changed since then (May '08).  For
> ActiveMessaging, it looks like Andrew implemented his own max retry logic
> (
> https://trac-git.assembla.com/breakout/browser/vendor/plugins/activemessaging/lib/activemessaging/adapters/stomp.rb?rev=a288646f5565a84e1358d827e889b13ea73abca4
> )
> 
> Thanks,
> 
> Roger
> 
> 

-- 
View this message in context: http://www.nabble.com/STOMP-redelivery-policy-tp22141094p23390201.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.