Setting JMSReplyTo field to NULL causes IllegalArgumentException to be thrown
-----------------------------------------------------------------------------
Key: QPID-1623
URL: https://issues.apache.org/jira/browse/QPID-1623
Project: Qpid
Issue Type: Improvement
Components: Java Client
Affects Versions: M4, M3, M2.1, M2, M1
Reporter: Marnie McCormack
Assignee: Aidan Skinner
Fix For: M5
Qpid versions 2.2.2.0
Platform: Windows
JDK: 16.0_11
I came across this problem while trying to write an example application for one
of our MAF clients that would take part in a JMS request-response message flow.
During testing of this I started hitting this IllegalArgumentException from
Qpid exception:
java.lang.IllegalArgumentException: Null destination not allowed
at
org.apache.qpid.client.message.AbstractJMSMessage.setJMSReplyTo(AbstractJMSMessage.java:200)
at
org.mule.providers.jms.JmsReplyToHandler.processReplyTo(JmsReplyToHandler.java:79)
at org.mule.impl.model.DefaultMuleProxy.onCall(DefaultMuleProxy.java:297)
at org.mule.impl.model.seda.SedaComponent.doSend(SedaComponent.java:406)
at
org.mule.impl.model.AbstractComponent.sendEvent(AbstractComponent.java:407)
at org.mule.impl.MuleSession.sendEvent(MuleSession.java:349)
at
org.mule.routing.inbound.InboundRouterCollection.send(InboundRouterCollection.java:197)
at
org.mule.routing.inbound.InboundRouterCollection.route(InboundRouterCollection.java:163)
at
org.mule.providers.AbstractMessageReceiver$DefaultInternalMessageListener.onMessage(AbstractMessageReceiver.java:585)
at
org.mule.providers.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:322)
at
org.mule.providers.AbstractReceiverWorker$1.doInTransaction(AbstractReceiverWorker.java:107)
at
org.mule.transaction.TransactionTemplate.execute(TransactionTemplate.java:98)
at
org.mule.providers.AbstractReceiverWorker.doRun(AbstractReceiverWorker.java:124)
at
org.mule.providers.AbstractReceiverWorker.run(AbstractReceiverWorker.java:60)
at org.mule.impl.work.WorkerContext.run(WorkerContext.java:310)
at org.mule.impl.work.SyncWorkExecutor.doExecute(SyncWorkExecutor.java:39)
at org.mule.impl.work.MuleWorkManager.executeWork(MuleWorkManager.java:277)
at org.mule.impl.work.MuleWorkManager.doWork(MuleWorkManager.java:169)
at
org.mule.providers.jms.MultiConsumerJmsMessageReceiver$SubReceiver.onMessage(MultiConsumerJmsMessageReceiver.java:281)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:719)
at
org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:656)
at
org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3043)
at org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:2966)
After doing some digging through the Mule code I was able to track it down to
the following piece of code in Mule's JmsReplyToHandler where it tries to set
the JMSReplyTo field to be null.
final boolean topic =
connector.getTopicResolver().isTopic(replyToDestination);
session = connector.getSession(false, topic);
Message replyToMessage = JmsMessageUtils.toMessage(payload, session);
replyToMessage.setJMSReplyTo(null);
if (logger.isDebugEnabled())
{
logger.debug("Sending jms reply to: " + replyToDestination + "("
+ replyToDestination.getClass().getName() + ")");
}
replyToProducer = connector.getJmsSupport().createProducer(session,
replyToDestination, topic);
The corresponding code in qpid (taken from the AbstractJMSMessage class) shows
that qpid throws the IllegalArgumentException whenever it receives a null
value:
public void setJMSReplyTo(Destination destination) throws JMSException
{
if (destination == null)
{
throw new IllegalArgumentException("Null destination not allowed");
}
if (!(destination instanceof AMQDestination))
{
throw new IllegalArgumentException(
"ReplyTo destination may only be an AMQDestination - passed
argument was type " + destination.getClass());
}
final AMQDestination amqd = (AMQDestination) destination;
final AMQShortString encodedDestination = amqd.getEncodedName();
_destinationCache.put(encodedDestination, destination);
getContentHeaderProperties().setReplyTo(encodedDestination);
}
The JMS Spec is a bit vague around whether or not you can actually set this
JMSReplyTo value to null or not but after talking with Martin about this he was
able to check both the Qpid and MQ code to see how they compared. While the
Qpid code disallows setting a null value on the JMSReplyTo field the MQ code is
more forgiving and allows Null values to be set. I've included the JMSReplyTo
section from the JMS Spec below.
-----
3.4.6 JMSReplyTo
The JMSReplyTo header field contains a Destination supplied by a client when a
message is sent. It is the destination where a reply to the message should be
sent.
Messages sent with a null JMSReplyTo value may be a notification of some event
or they may just be some data the sender thinks is of interest. Messages sent
with a JMSReplyTo value are typically expecting a response. A response may be
optional; it is up to the client to decide.
-----
Ideally I would like for this null check in the qpid code to be removed if
possible as at the moment it's stopping me from using qpid for this example for
one of our clients.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
