Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
0.26
-
None
-
Java
Description
I think the client violates the delivery guarantee of JMS with persistent messages.
Here is my test:
1. Start a qpid-cpp broker. Create a persistent queue on that broker
2. Start a test Java application using the amqp 1.0 JMS client. The application will write 10,000 persistent messages into the just created queue.
3. After some time while the client is still writing messages into the queue, I kill the broker (kill -9 <pid>) simulating the worst disaster scenario
4. My client code throws an exception and reports 4,963 messages sent
5. After re-starting qpidd, the queue statistics reports only 4,816 messages in the queue!
Here are some of the relevant code snippets from the client:
// Creating a Session
Session session = brokerConn.getConnection().createSession(false, Session.AUTO_ACKNOWLEDGE); // NOTE AUTO_ACKNOWLEGE does not have any effect with nessage producer
// Create a destination
Destination dest = session.createQueue(queueName);
// Creating a MessageProducer
MessageProducer msgProducer = session.createProducer(dest);
msgProducer.setDeliveryMode(2); // 2 == persistent
And then in a loop 1000 times with a random TextMessage I call:
msgProducer.send(msg);
So, it looks like the client is sending the message to the broker and the "send(msg)" method returns before either the broker acknowledged receiving and persisting the message, or the client does some internal caching.
By the way, I see the exact same issue when using ActiveMQ 5.9.0 as the broker using the AMQP connector.
However, it is also possible that the bug is within the proton library on the server side which is being used in both the qpid-cpp broker (proton-c) and ActiveMQ 5.9.0 (proton-j) to support AMQP 1-0.