Serious problem with DLQ in 2.4.4

[baltie]

Hi,

I've played a bit with JBossMQ in 2.4.4 and I've hit upon a bug which occur in relation to DLQ.

What happens is this. I've got two computers, A and B. Both are running JBoss 2.4.4 and both contains rather simple MDBs. Computer A's MDB, MDBA, accepts ObjectMessages. These messages are copied and sent to computer B's MDB, MDBB, which just prints out some info about the transmitted object.

The reason for this is simple. On computer A, there runs a client program. This program periodically needs to transmit data to a central server. Since this link isn't guaranteed to be available at all times, data is first sent to a local queue on computer A. The local queue then attempts to open a session with the remote queue on computer B. If it fails, context.setRollbackOnly in MDBA is called and a message is logged. If a session is created, the message is copied and sent to MDBB (this is a work-around the fact that ExceptionListener isn't implemented). This seems to work.

Well, with the introduction of 2.4.4, after the message has failed five times, the message is sent to DLQ instead. Which is a Good Thing. However... Lets say I transmit three messages and two out of three succeeds in being sent to computer B. Now if I shut down the JBoss server and then restarts it, two things happen:
1. A new set of dat-files are created in db/jbossmq and the old set is not deleted. (In normal runs where DLQ hasn't been involved, a new set is created, but the old one is gone.) The sizes of the files of the old set tells me that the DLQ contains the single message.
2. The message that couldn't be sent is resent, lets say this time successfully.

JBoss is then stopped again and then restarted. This time a new set of dat-files is created, the dat-files from the previous session is deleted, but the old ones from the first session is still around. Nothing is sent.

And again JBoss is restarted. And again a new set of dat-files is created and the set from the first session is still around. This time however, the message that failed in the first session and succeeded in the second, is resent ... again.

I can rinse and repeat as many times as I'd like. It's totally reproducable on my computer. Hope you can fix this problem until next release. :)

Well, only reason I upgraded to 2.4.4 was to see if ExceptionListener was included (as it was reported to be in the CVS HEAD). As far as I could see, it wasn't. And I guess our customer won't be too thrilled about the recurring messages problem, so I guess we'll downgrade to 2.4.3.

Thanks for any pointers, help and suggestions to alternative approaches, and do not hesitate to contact me if you need more information.

Cheers,
Dan

[pra]

This sound like an old bug in JBossMQ. I am pretty shure it works fine in the 3.0 series. I have never got to like the dat files. Could you check if you can change your persistence engine:

<!-- The PersistenceManager is used to store messages to disk. -->
<!--

../../db/jbossmq/

-->

../../db/jbossmq/


in jboss.jcml (.xml).

If everyting works, messages sent to DQL should never also be available in the original destination directory. If it is, then the acking is broken in JBossMQ.

//Peter

[baltie]

Well, what do you know, setting the persistence manager to file based fixed the problem. However, the persistence manager now complains that the various created directories in db/jbossmq aren't valid transaction record files. No worries though.

The messages in the DLQ are never resent now either, so now the behavior is at least consistent. But I have a feeling 2.4.x would've been better off without DLQ right now, giving the apparent problems with the default setup. :)

Well, now I only have to find a sensible way to administrate the messages in DLQ...

Cheers,
Dan

[pra]

I do think that the backporting of JBossMQ has not been done correct, since the bugfix for message resendiing is - as far as I could find out - not fixed in the backported version.

Nice that it worked with the better persistence manager.

//Peter