Hi Chris, thanks for your info. I added a similar test to verify this
behavior in my project.
On Wed, Jul 31, 2013 at 11:08 PM, Christian Posta wrote:
> So keep in mind that nak_limit on the broker side is the number of poison
> pills the broker will accept before moving a message to dlq.
>
> I
So keep in mind that nak_limit on the broker side is the number of poison
pills the broker will accept before moving a message to dlq.
I'm guessing in your ActiveQM 5.x client, you are expecting your redelivery
policy to send back an nack for each rollback? ...but it doesn't. It sends
a nack (pois
I use OpenWire protocol on the client side, where connection is created by
ActiveMQConnectionFactory
On Wed, Jul 31, 2013 at 9:43 PM, Christian Posta
wrote:
> What protocol are you using on the client side?
>
>
> On Wed, Jul 31, 2013 at 6:31 AM, Yong Ouyang
> wrote:
>
> > Hello,
> >
> > I am pl
What protocol are you using on the client side?
On Wed, Jul 31, 2013 at 6:31 AM, Yong Ouyang wrote:
> Hello,
>
> I am playing with Apollo 1.6 recently. Given the below config, I am
> expecting a dead message (being rolled back 3 times, for example) of queue
> "app1.queue1" will be forwarded to
Hello,
I am playing with Apollo 1.6 recently. Given the below config, I am
expecting a dead message (being rolled back 3 times, for example) of queue
"app1.queue1" will be forwarded to the dead letter queue "dlq.app1.queue1".
But this doesn't actually happen at all. Did anyone encounter the same
b
