Reputation: 364409
I'm working on something which could be described as custom WMQ message router/forwarder. At the moment I have some very confusing issue with processing JMS messages send over MQ. I'm able to receive message send from Java application over JMS (with MQ as transport) but I'm not able to send message to Java application listening on JMS endpoint.
I have a testing servlet and message driven bean - both hosted in WebSphere Application Server 7.0 (with WebSphere MQ 7.0 used for message transport). Servlet is able to communicate with the bean but if I put my forwarder between them (by reconfiguring the servlet to communicate with forwarder which will reconstruct messages and forward them to bean) the bean is not able to process the request. I have this error in WAS log:
[8/2/12 14:38:51:359 CEST] 00000031 SibMessage W [:] CWSJY0003W: JMSCC0110: An exception '
Message : java.lang.NullPointerException
Class : class java.lang.NullPointerException
Stack : com.ibm.msg.client.wmq.internal.messages.WMQMessageBase._parseMcdFolder(WMQMessageBase.java:445)
: com.ibm.msg.client.wmq.internal.messages.WMQReceiveMarshal.constructProviderMessageFromRFH2(WMQReceiveMarshal.java:341)
: com.ibm.msg.client.wmq.internal.messages.WMQReceiveMarshal.createProviderMessage(WMQReceiveMarshal.java:447)
: com.ibm.msg.client.wmq.internal.messages.WMQReceiveMarshal.exportProviderMessage(WMQReceiveMarshal.java:607)
: com.ibm.msg.client.wmq.internal.WMQConsumerShadow.getMsg(WMQConsumerShadow.java:1115)
: com.ibm.msg.client.wmq.internal.WMQSyncConsumerShadow.receive(WMQSyncConsumerShadow.java:334)
: com.ibm.msg.client.wmq.internal.WMQSession.loadMessageReference(WMQSession.java:1082)
: com.ibm.msg.client.jms.internal.JmsSessionImpl.consume(JmsSessionImpl.java:2847)
: com.ibm.msg.client.jms.internal.JmsSessionImpl.run(JmsSessionImpl.java:2549)
: com.ibm.mq.jms.MQSession.run(MQSession.java:860)
: com.ibm.mq.connector.inbound.WorkImpl.run(WorkImpl.java:172)
: com.ibm.ejs.j2c.work.WorkProxy.run(WorkProxy.java:399)
: com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1604)
[8/2/12 14:38:51:781 CEST] 00000031 SibMessage W [:] CWSJY0003W: MQJCA4004: Message delivery to an MDB 'XXX' failed with exception: 'null'
The message endpoint is automatically paused after this error.
I used RFHUtils to get messages send by both JMS and my app and compared them - there is no real difference in UI (except different delivery mode but that is another story) but when I saved messages to file and compared them I saw this difference (just first RFH2 folder):
Send by JMS directly:
<mcd><Msd>jms_text</Msd></mcd>
Send by my app:
<mcd><Msd dt="string" >jms_text</Msd></mcd>
All elements in RFH2 also contains type. Elements from jms
folder are in different order but according to exception the problem should be directly with mcd
folder. I'm not sure how to better diagnose the issue - I've tried to configure tracing for JMS but I don't know how to do that for WAS (I used WAS on Tuesday for the first time). Standard MQ trace doesn't provide any more information.
My .NET code (WMQ API using MQ Client 7.5 - amqmdnet.dll 7.5.0.0) is quite complex but it generally does:
Receiver
MQMessage
message by standard Get
call on MQQueue
accessed with MQOO_INPUT_AS_Q_DEF
(no special get options)MQMessage
GetPropertyNames("%")
to get names of all message propertiesGetObjectProperty
to get values for every propertyMQSTR
reads body by ReadString
otherwise by ReadBytes
Sender
MQMessage
MQMessage
- for example MessageId
, ReplyToQueue
name and some other are not copied - new or correct values are used insteadMQMessage
by using SetObjectProperty
- this step contains some magic because .NET API is inconsistent and the type of value returned from GetObjectProperty
is not always accepted by SetObjectProperty
- typically I receive String
but I must pass int
or long
(examples: JmsDeliveryMode, JmsPriority or JmsTimestamp). This step also overrides destinations for JmsDestination and JmsReplyToWriteString
or WriteBytes
Put
message to MQQueue
accessed with MQOO_OUTPUT
(no special put options)I don't create RFH2 structure manually - I let MQ infrastructure to deal with it. So my question: How to create valid JMS message from .NET which will be accepted by message driven bean?
Note: I don't want to use IBM.XMS - this decision was made long time ago because of some article in IBM knowledge base describing pros and cons of both XMS and WMQ. I need to support both JMS and non-JMS messaging.
Upvotes: 1
Views: 2175
Reputation: 364409
After enabling WebSphere tracing and using Java Decompiler to check some WebSphere .jar packages I found the reason for the error by a pure chance.
The tracing has shown what values are passed to the failing _parseMcdFolder
method:
[8/3/12 12:16:00:199 CEST] 0000003a > UOW= source=com.ibm.msg.client.wmq.internal.messages.WMQMessageBase method=_parseMcdFolder(String,String,String) (com.ibm.msg.client.wmq.internal.messages.WMQMessageBase) [:] org=IBM prod=WebSphere component=Application Server thread=[WMQJCAResourceAdapter : 0]
Entry parm0=<mcd><Msd dt="string" >jms_text</Msd></mcd> parm1=jms_text parm2=<null>
[8/3/12 12:16:00:199 CEST] 0000003a 3 UOW= source=com.ibm.msg.client.jms.internal.JmsSessionImpl org=IBM prod=WebSphere component=Application Server thread=[WMQJCAResourceAdapter : 0]
(com.ibm.msg.client.jms.internal.JmsSessionImpl) [:/50d450d4] Caught exception: java.lang.NullPointerException in class: com.ibm.msg.client.jms.internal.JmsSessionImpl method: run() <exitIndex: 2>
[8/3/12 12:16:00:199 CEST] 0000003a 1 UOW= source=com.ibm.msg.client.jms.internal.JmsSessionImpl org=IBM prod=WebSphere component=Application Server thread=[WMQJCAResourceAdapter : 0]
(com.ibm.msg.client.jms.internal.JmsSessionImpl) [:/50d450d4] Tracing exception:
java.lang.NullPointerException
at com.ibm.msg.client.wmq.internal.messages.WMQMessageBase._parseMcdFolder(WMQMessageBase.java:445)
at com.ibm.msg.client.wmq.internal.messages.WMQReceiveMarshal.constructProviderMessageFromRFH2(WMQReceiveMarshal.java:341)
at com.ibm.msg.client.wmq.internal.messages.WMQReceiveMarshal.createProviderMessage(WMQReceiveMarshal.java:447)
at com.ibm.msg.client.wmq.internal.messages.WMQReceiveMarshal.exportProviderMessage(WMQReceiveMarshal.java:607)
at com.ibm.msg.client.wmq.internal.WMQConsumerShadow.getMsg(WMQConsumerShadow.java:1115)
at com.ibm.msg.client.wmq.internal.WMQSyncConsumerShadow.receive(WMQSyncConsumerShadow.java:334)
at com.ibm.msg.client.wmq.internal.WMQSession.loadMessageReference(WMQSession.java:1082)
at com.ibm.msg.client.jms.internal.JmsSessionImpl.consume(JmsSessionImpl.java:2847)
at com.ibm.msg.client.jms.internal.JmsSessionImpl.run(JmsSessionImpl.java:2549)
at com.ibm.mq.jms.MQSession.run(MQSession.java:860)
at com.ibm.mq.connector.inbound.WorkImpl.run(WorkImpl.java:172)
at com.ibm.ejs.j2c.work.WorkProxy.run(WorkProxy.java:399)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1604)
So parameters passed to _parseMcdFolder
were:
parm0=<mcd><Msd dt="string" >jms_text</Msd></mcd> parm1=jms_text parm2=<null>
I decompiled the WMQ resource adapter package stored in %WAS_INSTALL%\lib\WMQ\ra\wmq.jmsra.rar
and checked the _parseMcdFolder
method. Surprisingly the reported line from exception and the method code didn't correspond (there was another method). Also the code of the method should correctly parse the passed parameter.
After a while I checked whole WAS installation directory and I found two occurrences of unpacked resource adapter - one was in root InstalledComponents
directory and second was in InstalledComponents
directory of the server profile. These resource adapters had different versions:
After decompiling the code for version 7.0.0.0-k700-L080820 I found that there is really a bug - accessing not initialized message:
static WMQMessage _parseMcdFolder(String s, String fbClass, String forcedMessageClass)
throws JMSException
{
WMQMessage newMessage = null;
// 350+ lines of code trying to parse s and initialize newMessage
// but no fallback so newMessage could be null after the processing
newMessage.isNullMessage = isNullMsgFlag; // Line 445 - BOOM!
return newMessage;
}
This bug was fixed in some following version of the adapter but it was not communicated because I didn't find any documentation related to this issue.
After using the newer adapter version the problem was resolved (actually I have moved just to another problem).
Upvotes: 1