File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes ActiveMq NonBlocking Redelivery Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "ActiveMq NonBlocking Redelivery" Watch "ActiveMq NonBlocking Redelivery" New topic
Author

ActiveMq NonBlocking Redelivery

Pankaj Shet
Ranch Hand

Joined: Sep 08, 2006
Posts: 225

Hi Guys,

I am using activeMq version 5.7.x,

I am having one ActiveMq queue to which the listener listens.

Queue has a ConnectionFactory whose redeliveryPolicy is set to 3, intialRedeliveryDelay set to 5000.

Queue have some good messages and bad messages.

While listening to such queue, when bad messages come, they are tried 3 times with the wait time of 5000 millis, but then the good messages are blocked for that much time span.

What I want is, during the wait time of 5000 millis for each retry, the processing of good messages should continue and should not wait for bad message processing.

For this I tried 1 attribute of connectionFactory, i.e. nonBlockingRedelivery set to true.

But nonBlockingRedelivery is not working.

Is there any other way to do this?

Regards,
-Pankaj




PANKAJ SHET
B.Sc.(I.T.), S.C.J.P., S.C.W.C.D., PGDAC(CDAC)
Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 444
    
    1

What does *bad* and *good* mean in your use case ?
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18702
    
  40

Claude Moore wrote:What does *bad* and *good* mean in your use case ?


If I had to take a guess, I would think "bad" messages are messages that can't be processed, and hence, won't be acknowledged by the consumer.

In my opinion, there are two possibilities for this...

1. The producer is sending these "bad" messages.

2. There are consumers that isn't able to process all the message types in the queue.

For one, it is a bug. You should never have a producer generating junk. And as for the case where you accidentally ran a producer on the wrong queue ... well, that is a misconfiguration (ie. an edge condition), and you shouldn't need to optimize for it.

For two, I am completely not a fan of this. Consumers on a queue should be able to process all messages on the queue. Consumers should be equal, in that they should be able to process everything on the queue. The differences should be "how" they process, and not "if" they can process. The idea of using client acknowledge mode, and not acknowledging, are for errors (ie. edge conditions). Something is going wrong, and the client can't process messages anymore. It is not for normal operations -- where a client wants to "reject" a message.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18702
    
  40


To try to answer the original question ... and note that I am not an ActiveMQ user, so this answer may not completely apply.

I believe that consumers should be operating independently. Meaning that if a consumer is stuck on a message, the other consumers should still be working. The queue should not be blocked because of one consumer.

Henry
Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 444
    
    1

Henry Wong wrote:
I believe that consumers should be operating independently. Meaning that if a consumer is stuck on a message, the other consumers should still be working. The queue should not be blocked because of one consumer.


In this hypothesis, there are more than one listener to a queue; I don't believe that a queue is locked (and doesnt' send messages to other listeners) if one consumer is stuck at one single message. Just think about
a queue used to distribute unit of work to different processors: it would be a severe limitation if queue were blocked. Or am I wrong ?
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18702
    
  40

Claude Moore wrote:
In this hypothesis, there are more than one listener to a queue; I don't believe that a queue is locked (and doesnt' send messages to other listeners) if one consumer is stuck at one single message. Just think about
a queue used to distribute unit of work to different processors: it would be a severe limitation if queue were blocked. Or am I wrong ?


Side note. I don't use the JMS API much (opting for the native API when doing messaging), so this response may not apply to JMS.

Agreed. It would be a severe limitation if the queue would block all the consumers because one consumer is busy -- so I too, don't believe that JMS does this (although I haven't tested it).

As for the ability to give another message to a consumer (who seem to be busy with a previous message), that feature is available too. In some of the environments that I use, you can configure a number of messages to be placed at risk -- meaning send a maximum number of outstanding messages to a consumer. This means that in the case of a consumer application dying, and taking the messages with it, the queue has to timeout and reassign lots of messages (and not just one).

Henry
Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 444
    
    1

Henry, you describe interesting features of JMS MOM systems. By the way, can you share with us which "native API" do you use for messaging? It's quite interesting.
Pankaj Shet
Ranch Hand

Joined: Sep 08, 2006
Posts: 225

Thanks claude and Henry for your reply,

Bad messages are those messages which throw exceptions while getting processed and by default, they are tried to be processed 6 or 7 times as per the default Redelivery Policy.
Good Messages are those messages which do not throw any exceptions and are processed successfully.

But when the bad messages are getting processed and are being retried, the processing of good messages is blocked..

i.e suppose if there are 10 messages in the queue, 1st message is processed successfully, 2nd message is processed successfully, 3rd message is processed successfully, but 4th message fails, while 4th fails what happens is, the 4th message is tried tried for redelivery 6-9 times at certain time period. suppose 10 seconds each, it will take 60 - 90 seconds to process that message, and if that processing is failed and that message moves to dead letter queue.
WHilw 4th message is being retried and redelivered, all the messages from 5th message onwards, have to wait for 60-90 seconds.

what is needed is that, those messages need not wait for the bad message processsing.

So for that purpose, ActiveMq provides the ActiveConnectionFactory attribute: nonBlockingRedelivery which according to ActiveMq API documentation, when set to true, will not block the other good messages from processing while bad messages are redelivered.

But the same is not working when actually applied.


So we found one solution:

We mentained other queue, called a redelivary queue.
we check If that message is redelivered, If yes it will be moved to the redelivery Queue, so that remaining good message will continue processing and the bad message will be retried and redelivered in the redelivery queue.

But the questions is that why do we need to do all this when the solution is available readily in the activeMq API Docs.? (setting nonBlockingRedelivery= true attribute of ActiveMqConnectionFactory) which is not working?



Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18702
    
  40

Pankaj Shet wrote:
Bad messages are those messages which throw exceptions while getting processed and by default, they are tried to be processed 6 or 7 times as per the default Redelivery Policy.
Good Messages are those messages which do not throw any exceptions and are processed successfully.

But when the bad messages are getting processed and are being retried, the processing of good messages is blocked..

i.e suppose if there are 10 messages in the queue, 1st message is processed successfully, 2nd message is processed successfully, 3rd message is processed successfully, but 4th message fails, while 4th fails what happens is, the 4th message is tried tried for redelivery 6-9 times at certain time period. suppose 10 seconds each, it will take 60 - 90 seconds to process that message, and if that processing is failed and that message moves to dead letter queue.
WHilw 4th message is being retried and redelivered, all the messages from 5th message onwards, have to wait for 60-90 seconds.

what is needed is that, those messages need not wait for the bad message processsing.


Why do you need this long dance of, message timeout --> reassignment & redelivery --> yadda yadda yadda for six to nine more times --> dead letter queue? Will there be a chance that the message will get processed on redelivery?

If not, and it will fail every time, then this is a bad message. It can't ever be processed, why do you need ActiveMQ to redelivery so many times, when you know it will fail every time?

Just create an application specific "failed processing dead letter queue", and when a bad process occurs, send the message to the app specific dead letter queue, acknowledge the message as processed, and move on.

Henry
Pankaj Shet
Ranch Hand

Joined: Sep 08, 2006
Posts: 225

HI Henry,


Will there be a chance that the message will get processed on redelivery?

If not, and it will fail every time, then this is a bad message. It can't ever be processed, why do you need ActiveMQ to redelivery so many times, when you know it will fail every time?

Just create an application specific "failed processing dead letter queue", and when a bad process occurs, send the message to the app specific dead letter queue, acknowledge the message as processed, and move on.

Henry



I think yes, There are chances of message getting processed on redelivery, For eg, the message may fail due to connectivity issue or the network issue?
If that is the case, then there are chances that message may get processed on redelivery?

Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 444
    
    1

Henry's suggested approach is very clean and effective. Don't forget that being unable to process a message due to some system problem (as you stated, a network failure, a database issue and so on) is quite different to being unable to process it due to some application problem (i.e unsufficient data in payload message, bugs on your code and so on). In my humble experience, i used to use a MessageGateway component which is responsible to talk with MOM; it reads messages, dispatches them to listeners component I can register within my message gateway, and always sends an ack back to MOM. Of course, sending always acks back isn't always a feasible approach; but it's quite enough when messages aren't part of a transaction - juat they are used to notify clients that events are occurred (evemts are, for example: a teport is ready to download, a batch task has been executed and so on). Anyway dead messages queue is absolutly a good idea.
Pankaj Shet
Ranch Hand

Joined: Sep 08, 2006
Posts: 225

Hi Claude,

but it's quite enough when messages aren't part of a transaction - juat they are used to notify clients that events are occurred


My messages are the part of transaction...

My messages connect to database and if the database server is down for 2 minutes, it may fail for two minutes, and may reconnect after 2 mins?

So the bad messages may convert to good messages.. after redelivery and retries?



Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 444
    
    1

Mmmm... with transaction do you mean a single atomic unit of work, which may be committed or rolled-back, or, more generally speaking, a more or less complex workflow ? Usually transactions should be completed in a few seconds, and that doesn't seem your case. Anyway, as Henry previously explained, your scenario seems unnecessarily complex. Messages producer may be notified that a client rejected a message, and then try to send it again. But i would leave retransmission mechanism on only for system errors ( network outages), not for business- related problems.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: ActiveMq NonBlocking Redelivery