I am writing a Java client that will post messages to Sonic. By default, the JMSDeliveryMode is set to NON_PERSISTENT. I attempted to set the JMSDeliveryMode with this code:
TextMessage textMessage = (TextMessage) sendSession.createTextMessage();
MessageProducer messageProducer = sendSession.createProducer(sendQueue);
The message on the queue still has a JMSDeliveryMode set to NON_PERSISTENT. Is there some sort of trick to setting this value? I posted it to a queue where no ESB process was listening, so no Endpoints are involved here.
Message was edited by:
I resolved the issue today. I still don't understand why my original code did not work, but here is what i did to fix the problem.
//Use the method on send() that allows you to set the Delivery Mode instead of setting it on the message itself
messageProducer.send(textMessage, DeliveryMode.PERSISTENT, Message.DEFAULT_PRIORITY, MESSAGE_LIFESPAN);
nweddle wrote:I I still don't understand why my original code did not work,
I I still don't understand why my original code did not work,
In case you are wondering, the reason your original code did now work is that it was not following the JMS Specification. In JMS, when a message is sent, the following are set only on the "publish" or "send" method -- not on the message:
- Delivery Mode
- Expiration (Time to Live)
Because one JMS client can take a message off one queue, and then send it to another (or to many), the JMS Spec says that you shouldn't automatically 'copy' the values of the above 4 JMS properties from the message in the client to the message on the wire. (This also would apply to JMSMessageID. That is, you can make a new message, set the JMS Message ID, and then send it, but the 'send' operation creates a new message id.)
You may then ask... "If the JMS Spec says that you can't use the DeliveryMode, Priority, Destination, MessageID from the JMS Message, why are there methods in the spec like "setDeliveryMode()" or 'setMessageID()' ? This is a good question and the answer is that JMS also requires that one provider must be able to 'send' a message created by another provider. However, if provider A sends a message that is an object created by provider B, then the message still needs to have its Destination, MessageID, etc set after the send occurs, so Provider A needs to call these methods. Frankly it is not a use I've seen much, but that is the spec.