We're doing some extensive fail-safe tests on the MQ using JBoss 3.0.4 on a Windows NT platform, and have run into a serious problem.
We're trying to use JBossMQ to asynchronously transmit critical data from one server to another. The idea here is that if the receiving server is down, the sending server holds the data in its own queue until the receiving server is up again, whereupon data transmission starts again. Both queues only have transacted sessions and only messages with the DeliveryMode.PERSISTENT flag are sent. Both queues use the file persistence manager.
This seems to work, but then someone decided to cut the power to the receiving computer during transmission of data. The result got ugly. The sender, computer A, sent a bulk of messages to the receiver, computer B. All the send-calls on A went without problems. During processing of the messages, B is shut down. When B is booted up again, there are several files in the db\jbossmq\queue.a-directory which are just empty. They should've contained the transmitted data, but apparently the data hasn't been flushed to disk yet.
This behavior is unacceptable, as all the data contained in the messages are critical to the customer, and power shortages may occur.
I'm not even sure this can be attributed as a bug in JBossMQ, but we need a solution nevertheless. We have tried the JDBC2 PM, using MySQL as the database. This worked if we used the flush option and repaired the tables after booting, but it's far from an ideal solution. Other ideas are accepted with gratitude. We've toyed with the idea of keeping the data on the sender side after transmission and let another bean wait for a confirmation from the server that the data has been processed.
What do you think? What would be a feasible solution to our dilemma?
Dan
