JBossDeveloper

Out of curiosity:

David Hawes wrote:

 

Now, suppose that I have two messages in the topic.  The first message is received, rolled back, and immediately followed by the second message (maxSession=1 and maxMessages=1).  n number of messages will come in rapid succession, and that is what I mean by message thrashing.

 

How is this any different from the normal message processing (when redelivery is not involved)? You have 1000s of messages in the queue and the MDB is processing them one at a time. The MDB processing could take just a few milli seconds and complete successfully. So you would see messages coming in, in rapid succession. I am trying to understand, why this is specific to redelivery delay?

David Hawes wrote:

 

The behavior I want is for the second message to be delivered 5 seconds after the first message is rolled back.  So, in essence, I want the redelivery delay to take place for the entire topic.

Again, I'm not sure about the usecase here. But I have a feeling that you are thinking about just one specific scenario for the redelivery to be triggered. Based on another post in this thread, I guess you are thinking that the redelivery is almost always going to happen because of some external service being down. Am I right? If that's what you are trying to solve, then I guess setting a redelivery delay on the topic/queue isn't really the right way to handle this.

dfisher wrote:

 

If your consumer relies on some external service in order to successfully process messages, dealing with the availability of that service can be a difficult problem.

Do you have control over the external service? I mean can you monitor (through some automated tool or some other means) when it comes back to life? If yes, then you might be interested in JBoss specific "DeliveryActive" activation config on the MDB. See this doc for details. So once the external service comes back to life, you can start() the MBean corresponding to your MDB. This may not be an ideal solution, but something you can think about.

We have redelivery *delay* as a feature on HornetQ. The message will be redelivered in X seconds, after a given timeout. (post edited this paragram... I meant "redelivery delay" is a feature, not just "redelivery" as I mistyped it originally)

What the user wants is different. He wants the message to come back at the top (as it would happen without redelivery delay), but he wants the whole delivery to be paused for X seconds, and that would be a feature request ATM.

I'm not really sure if the use case makes sense either. It seems to me, a simple redelivery would suffice on his case.

Message was edited by: Clebert Suconic

Can you rethink how your application works, i always find once a solution becomes convoluted because a technology doesnt do just what you want then you either need to use a different technology or rethink what you want your application to do.

However, here is a possible solution, use 2 destinations, the first is a feeder destination where all the messages are sent, this has an MDB listening to it which basically feeds the second queue. The second queue has the actual MDB listening on it which is your business logic. Now, if u set the AddressFullMessagePolicy to block on the second destination and set the correct max size of the destination to 1 message then the first MDB will block sending another message to the destination until the second MDB has succesfully consumed and acknowledged its message. If the message is rolled back then the address is still full and the producer still blocks, even if the message is delayed it is still held by the destination, I think , clebert, am i right in how redelivery delay would work with the size of the address being sent to.

Andy Taylor wrote:

 

However, here is a possible solution, use 2 destinations, the first is a feeder destination where all the messages are sent, this has an MDB listening to it which basically feeds the second queue. The second queue has the actual MDB listening on it which is your business logic. Now, if u set the AddressFullMessagePolicy to block on the second destination and set the correct max size of the destination to 1 message then the first MDB will block sending another message to the destination until the second MDB has succesfully consumed and acknowledged its message. If the message is rolled back then the address is still full and the producer still blocks, even if the message is delayed it is still held by the destination, I think , clebert, am i right in how redelivery delay would work with the size of the address being sent to.

Getting the correct max-size-bytes would be tricky, there is a large variation in our message sizes.

Is there another flow setting that controls the absolute number of messages in a destination?

I have created the JIRA with a feature request here: https://jira.jboss.org/browse/HORNETQ-424

For now I think you should sleep (block) in case of redelivery. This shouldn't be a very frequent ocurrency, so you would be fine. Keep in mind that you will be blocking a thread when the redelivery happens.