Hm, it seems that I don't fully understand how consumers are working.
I've merged fix from the JMS and it seems working nice if there is a small
amount of messages to resend. But if I try to put a big amount of "bad"
messages in queue, I will still get the same behavior: all my consumers got
stuck
Okay, it seems I have 2 options:
1) Merge all changes from Java into NMS
2) Try to use camel case routes to define a rule. The scheme will be the
following:
* Consumer receives a message and it can't process it
* Consumer move message to its own DLQ, which is actually works as a
temporary storage
sorry, not sure about NMS. Keeping message order is the default so I
think NMS would need a similar enhancement to support out of order
delivery.
On 3 November 2011 14:18, Ishitori wrote:
> Hi, Gary.
>
> Thanks for the answer. I forgot to mention that I am using NMS. Does it make
> the difference
Hi, Gary.
Thanks for the answer. I forgot to mention that I am using NMS. Does it make
the difference? I mean, that you gave the link to ActiveMQ client code,
right? Is there something like that for NMS?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Redelivery-sticks-to-
try a current 5.6-SNAPSHOT
see: https://issues.apache.org/jira/browse/AMQ-1853
On 3 November 2011 11:54, Ishitori wrote:
> Is there any progress conserning this issue? I am using the latest version of
> ActiveMQ 5.5.0 and the situation is the same: consumer threads doesn't
> receive any messages
Is there any progress conserning this issue? I am using the latest version of
ActiveMQ 5.5.0 and the situation is the same: consumer threads doesn't
receive any messages until full redelivery cycle is completed.
Can this be somehow resolved? Expected behaviour is: failed to process
message is sent
OK, I found some time to test this on 5.1 myself. Unfortunately the issue is
NOT resolved as far as I can tell.
I don't see how anyone can live with this...
Consider a system which processes 100 messages/sec, with MaximumRedeliveries
to 8 for a total of let's say an hour (in case of network fail
Thanks,
So you can confirm that threads are no longer blocked during retries in 5.1?
Can I find any docs/info on the retry mechanism in 5.1 anywhere?
rajdavies wrote:
>
> I'd certainly try 5.1
>
> cheers,
>
> Rob
> On 6 Jun 2008, at 14:05, Demian Mrakovich wrote:
>
>>
>> Hi, bumping this
I'd certainly try 5.1
cheers,
Rob
On 6 Jun 2008, at 14:05, Demian Mrakovich wrote:
Hi, bumping this one... Has this (I'd have to say major) issue been
addressed
in newer versions of ActiveMQ?
Jason Rosenberg wrote:
All,
I have been experimenting with using exponentialBackOff as a
re
Hi, bumping this one... Has this (I'd have to say major) issue been addressed
in newer versions of ActiveMQ?
Jason Rosenberg wrote:
>
> All,
>
> I have been experimenting with using exponentialBackOff as a redelivery
> policy. I have multiple parallel consumers. I'm using AMQ 4.1.1, using
>
10 matches
Mail list logo
