Redelivery order

[szhigunov]

I ran into a problem that message redelivery order depends on if the server was restarted before redelivery or not.

This is my scenario.

I read three messages from the queue (sequentially) in separate transacted sessions and rollback them all.
Then, if I restart the server, the messages are redelivered in the order they were published (desired behavior).

If I do not restart the server, and begin receiving again (after all messages were rolled back to the queue),
the order of redelivery depends on the rollback timing.
The last to rollback is the first to redeliver and the original order is broken.

Is there a way to guarantee original message order in such situation without bouncing the server?

[szhigunov]

The work around may be to restart the queue using MBean interface.

So when client restarts after the failure, it does EJB / MBean remote call to restart the queue. That will restore the original message order.

Is there a better way?

[timfox]

If you rollback a transaction in which you have consumed three messages A, B, C, then the order will indeed be preserved on rollback with JBM.

However if you rollback each message in it's *own* transaction, then I don't think it's physically possible to guarantee any order.

Rollback just puts the messages back on the front of the queue. So it's the order is always going to depend on timing.

BTW the JMS spec does not require order of delivery to be preserved after rollback anyway.

[szhigunov]

Thanks for the clarification.

I still have the following question.

Can we rely on the assumption that after the queue restart, JBM will deliver messages strictly in the order they were sent,
even if for some of them it is redelivery?

At least that is what I see in my tests.

[timfox]

I think that's the case at the moment. But it's an implementation detail and subject to change.

If you rely on such details in your application, it will make it brittle and also non portable (so other messaging systems will probably have different behaviour since this is outside the JMS spec).

[mclu]

Hi!

Long Time ago I asked the same question.
There is a feature request under:
http://jira.jboss.com/jira/browse/JBMESSAGING-1151
for this!

I have the same problem and my customer wants to put the System life in a month. So I am very interested in solutions ( or feature request implementation ) :-)

Greets

[mclu]

Hi szhigunov!

I made some tests with the restart of the queues but I can not see it working.

Can you quickly tell me what you have done?

I did:
- At MDB Level I catch exception while handling Message A.
- Then I call context.setRollbackOnly()
- Then I get the MBeanserver and stop and start my Queue.

But next handled message is not the rolled back on (A) . Its another one (B) and the rolled back is handled later.


Thx for help!

[szhigunov]

1) Queue is deployed on the remote server.
2) My consumer is not an MDB. It is a normal JMS consumer deployed as MBean. It gets connection to the queue through JCA adapter.
3) I control the transaction using TransactionManager interface.
4) On RuntimeException, I close all JMS objects (consumer, session, connection) and rollback the transaction.
5) Then if I restart queue on the remote server and start my consumer again - messages are delivered in the correct order (in tests I did).

What happens if you not just restart the queue but restart the JBoss? Not a solution, just for information.

My logic was that restart would clear all buffers and force JBM to reread messages from DB (hopefully in the order they were written in the first place)

I am in a prototype phase, not sure if will try to use it or not.