| Author |
Message
|
| philexm |
 Posted: Fri Jul 20, 2012 8:30 am Post subject: Messages are in Q, but JMS client failed to get it sometimes |
 |
|
Newbie
Joined: 08 Jun 2012
Posts: 8
|
Guys,
I met an issue, my JMS client using SYNC way to receive msgs from MQ server, but it failed to get message back sometimes(not stable), and the expected response message can be found in the response Q from MQ explorer. Is there anything wrong in the JMS client or the other reason MQ server failed on getmsg operation? Any suggestions?
| Code: |
InitialContext context = new InitialContext(env);
QueueConnectionFactory queueConnectionFactory = (QueueConnectionFactory) context.lookup(connectionJndiName);
Queue requestQueue = (Queue) context.lookup(reqQueueJndiName);
Queue responseQueue = (Queue) context.lookup(resQueueJndiName);
queueConnection = queueConnectionFactory.createQueueConnection();
queueConnection.start();
queueSession = queueConnection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
queueSender = queueSession.createSender(requestQueue);
TextMessage message = queueSession.createTextMessage(textMessage);
Log.debug("Print message header property:");
for (Iterator iterator = parameters.entrySet().iterator(); iterator.hasNext();) {
Entry type = (Entry) iterator.next();
String key = (String) type.getKey();
String value = (String) type.getValue();
message.setStringProperty(key, value);
Log.debug("(" + key + " : "+ value + ")\t");
}
message.setStringProperty("loggingKey", corID);
message.setJMSCorrelationID(corID);
message.setJMSReplyTo(responseQueue);
queueSender.send(message, javax.jms.DeliveryMode.NON_PERSISTENT,javax.jms.Message.DEFAULT_PRIORITY, 30000);
String selectorReceive = "loggingKey = '" + corID + "'";
queueReceiver = queueSession.createReceiver(responseQueue, selectorReceive);
Message receiveMsg = queueReceiver.receive(resTimeout);
Log.info("JMSClient recieve message:" + receiveMsg); |
2012-07-19 12:20:30:934 [request2][3524734113-TR-85389] INFO - JMSClient recieve message:null
2012-07-19 12:20:30:935 [request2][3524734113-TR-85389] ERROR - Unexpected exception
java.lang.NullPointerException
at coc.taf.jms.JMSClient.getMessageHeaders(JMSClient.java:131)
at coc.taf.jms.JMSClient.sendToMQ(JMSClient.java:79)
at coc.taf.request.MQRequest.doRequest(MQRequest.java:54)
at coc.taf.request.TAFReqSession.request(TAFReqSession.java:155)
at coc.taf.request.TAFReqSession.execute(TAFReqSession.java:103)
at coc.taf.request.HostRequestExecuter$1.run(HostRequestExecuter.java:35)
at coc.taf.pool.SessionPool$1.run(SessionPool.java:83)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
at java.lang.Thread.run(Thread.java:534) |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Jul 20, 2012 8:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
You need to amend your code to capture the linked exception (there are examples of such code on this forum). This will give you the reason code from your get.
Moving to your code, Java is seriously not my thing but I'm always nervous when I see string values like "logging key" being used in a correlation (or message) id which isn't a string. Are you sure that sometimes that value isn't being converted so the selector doesn't match & you don't find the message?
Also, how do you know there's a response to read back? Can you browse it on the queue while your programme is looking for it? If you just see that the queue has depth it may be the response is not committed, or committed after your application's wait interval has expired.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| philexm |
| Posted: Fri Jul 20, 2012 9:38 am Post subject: |
|
|
Newbie
Joined: 08 Jun 2012
Posts: 8
|
| Vitor wrote: |
You need to amend your code to capture the linked exception (there are examples of such code on this forum). This will give you the reason code from your get.
Moving to your code, Java is seriously not my thing but I'm always nervous when I see string values like "logging key" being used in a correlation (or message) id which isn't a string. Are you sure that sometimes that value isn't being converted so the selector doesn't match & you don't find the message?
Also, how do you know there's a response to read back? Can you browse it on the queue while your programme is looking for it? If you just see that the queue has depth it may be the response is not committed, or committed after your application's wait interval has expired. |
Thanks for your reply,
I do have LINKED Exceptions catching block in my code, but there is nothing be caught that related to JMSException, JMS client just got timeout and print null as received msg.
the selector should be fine, since we did get most of response back. I am kind of agree you said the response msgs might not be commited for some cases. but is there any logs I can check fro MQ server side for this?
catch (JMSException jmsException) {
Log.error("JMSClient connection failure", jmsException);
Log.error("Linked Exception", jmsException.getLinkedException());
} catch (Exception exception) {
Log.error("Unexpected exception", exception); |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 20, 2012 9:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| philexm wrote: |
| I am kind of agree you said the response msgs might not be commited for some cases. but is there any logs I can check fro MQ server side for this? |
If the response messages are not committed at all then the number of messages visible in the queue will be smaller than the value of the queue depth property.
If the response messages are not committed inside the wait interval then you can check by seeing if you're able to manually browse the message while your application is still waiting for it to arrive. If you can't browse it, the application is waiting but the queue depth indicates there's a message there it's not committed. If you can browse it but your application is still waiting check the selector.
AFAIK the queue manager doesn't log commit activity. You can imagine the size of the log file if it did.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jul 20, 2012 10:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| You need to make sure the request message is committed or sent outside of a syncpoint before you wait for the response message. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 20, 2012 10:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| You need to make sure the request message is committed or sent outside of a syncpoint before you wait for the response message. |
Wouldn't that stop the code every working rather than just some of them? Or is there something variable and Java-esq about transactions in this context? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jul 20, 2012 10:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| mqjeff wrote: |
| You need to make sure the request message is committed or sent outside of a syncpoint before you wait for the response message. |
Wouldn't that stop the code every working rather than just some of them? Or is there something variable and Java-esq about transactions in this context? |
it would indeed keep it from working every time. The fact that it works sometimes doesn't necessarily mean that it's been eliminated as a possibility. It needs to be nailed down before the next thing is checked. Do one thing at a time, do it very well, and then move on.
EDIT: The other thing to do is ignore the requesting application entirely. Assume it's correct, and troubleshoot the behavior of the server application. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 20, 2012 10:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Posts about Java problems. I always get nervous offering advice. Especially on Fridays. Or any other day with a "y" in it's name. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jul 21, 2012 8:11 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And remember in Java JMS you don't get a 2033, you get a null message.
So the fact that you received a null message simply means "no message in queue satisfying request criteria". This may include changing / creating a new receiver because you need to change the message selector...
If this is a timing issue a get with a longer wait may be in order.
As said by my esteemed colleagues, make sure the put of the request is outside of the request / reply transaction or you will always time out on the reply
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
