Author |
Message
|
pjastrz |
Posted: Tue Dec 13, 2011 7:45 am Post subject: Message receiving failure after upgrade to v7 |
|
|
Newbie
Joined: 13 Dec 2011 Posts: 4
|
So we use mqseries to exchange messages with clients (receiving in that specific scenario). It is up to ~20mb of xml per message. So we used to use java MQ API. Our jars were 6.0 version, and queue manager are also v6. So recently we upgraded our codebase to use jms and v7 jars. We have some clients using v6, some v7 queue managers, but that specific client is using v6 queue managers. So it all worked in testing environment, but messages were sent by us, not client.
When it was deployed in production environment, we were not able to receive that messages, with generic error:
Code: |
So apparently this forum does not allow me to post links, unless I have at least one post. Also, it is interpreting my stack trace as link:) I will post stack trace as a reply.
|
So first of all I have no idea why it didn't reported some reason code, when I point it to non-existing queue it is reporting proper reason code, so it is not logging fault.
Secondly I tried to google that stack trace, found nothing.
So I was unable to reproduce it in testing environment, it all worked just fine. I was trying to use whole bunch of different apis, languages, version of jars etc to send messages to queue, but receiver consumed them all without issues.
Anyone have any tips what that might be, or what else can I try to cause that issue? Just to remind we upgraded to jms, and to v7 jars, so problem probably is somewhere there.
Please let me know if providing further information might help, but I tried to describe it in details  |
|
Back to top |
|
 |
pjastrz |
Posted: Tue Dec 13, 2011 7:46 am Post subject: |
|
|
Newbie
Joined: 13 Dec 2011 Posts: 4
|
Here is the exception/stack trace
Code: |
javax.jms.JMSException: MQJMS2002: failed to get message from MQ queue.
at com.ibm.msg.client.wmq.v6.jms.internal.ConfigEnvironment.newException(ConfigEnvironment.java:374)
at com.ibm.msg.client.wmq.v6.jms.internal.MQMessageConsumer.getMessage(MQMessageConsumer.java:3099)
at com.ibm.msg.client.wmq.v6.jms.internal.MQMessageConsumer.receiveInternal(MQMessageConsumer.java:4576)
at com.ibm.msg.client.wmq.v6.jms.internal.MQMessageConsumer.receive(MQMessageConsumer.java:4054)
at com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receiveInboundMessage(JmsMessageConsumerImpl.java:742)
at com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receive(JmsMessageConsumerImpl.java:321)
at com.ibm.mq.jms.MQMessageConsumer.receive(MQMessageConsumer.java:228)
|
|
|
Back to top |
|
 |
Vitor |
Posted: Tue Dec 13, 2011 7:51 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
There should be a linked exception that has additional details on that error.
Have you reviewed the JMS differences between WMQv6 & WMQv7 to eliminate them as a source of your problems? Especially as (if I read your post correctly) your client is still sending with v6? _________________ Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Tue Dec 13, 2011 7:52 am; edited 1 time in total |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Dec 13, 2011 7:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Ideally we want to see the linked exception as well as the main exception, this usually contains the MQRC.
In general, if you have code that works in one environment, and does not work in another environment, it is the environment that is at fault and not the code.
Except, of course, when investigation shows that it's the code and not the environment...
Can you reproduce the issue at all in the customer's other environments - i.e. not just production? That is, you say it works in testing environment - but is that your testing environment or theirs? Make sure you can test it in their test environment. |
|
Back to top |
|
 |
zpat |
Posted: Tue Dec 13, 2011 8:19 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Exact versions of WMQ please. |
|
Back to top |
|
 |
pjastrz |
Posted: Wed Dec 14, 2011 7:00 am Post subject: |
|
|
Newbie
Joined: 13 Dec 2011 Posts: 4
|
We upgraded from 6.0.2.1 to 7.0.1.0. The Queue manager is 6.0.2.1 as well.
Quote: |
deally we want to see the linked exception as well as the main exception, this usually contains the MQRC. |
That's one of main reasons I don't know how to proceed, there is nothing more about that issue in logs, just the stuff I pasted.
Quote: |
Can you reproduce the issue at all in the customer's other environments - i.e. not just production? |
It's ours production environment, we communicate with client by queue, the issue happens on our side, since we are trying to read from queue.
Quote: |
Have you reviewed the JMS differences between WMQv6 & WMQv7 |
Yes, I proceeded with some check list from IBM resources. |
|
Back to top |
|
 |
Vitor |
Posted: Wed Dec 14, 2011 7:06 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
pjastrz wrote: |
We upgraded from 6.0.2.1 to 7.0.1.0. The Queue manager is 6.0.2.1 as well. |
Why not apply maintenance? Lots of fixes between 7.0.1.0 & 7.0.1.4. There's also a fair few fixes available for that old version of v6 you're using.
pjastrz wrote: |
That's one of main reasons I don't know how to proceed, there is nothing more about that issue in logs, just the stuff I pasted. |
The linked exception is not produced by default, the application must be coded to record it to the log. I agree that without it you're going to have trouble proceeding as the default JMS error tells you very little.
pjastrz wrote: |
It's ours production environment, we communicate with client by queue, the issue happens on our side, since we are trying to read from queue. |
That's not an answer. Given that this is happening in your production environment, can you reproduce it in other environments? Where possibly a patched version of the code could report the linked exception for you?
How about the evironment where you tested the upgrade to WMQv7? As you must have testing it somewhere before applying it to production. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Dec 14, 2011 8:39 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
And please patch.
Decent JMS level in WMQ V7 starts at 7.0.1.4 and you should really be using 7.0.1.6 or above. _________________ MQ & Broker admin |
|
Back to top |
|
 |
pjastrz |
Posted: Wed Dec 14, 2011 9:09 am Post subject: |
|
|
Newbie
Joined: 13 Dec 2011 Posts: 4
|
Quote: |
That's not an answer. Given that this is happening in your production environment, can you reproduce it in other environments? Where possibly a patched version of the code could report the linked exception for you? |
That's the problem, we cannot reproduce it on certification environment. Since we cannot reproduce it, we can't use modified client, with proper logging, to extract linked exception. Unless we can reproduce it, we cannot apply any patches, changes etc, because there is no way to verify it fixed problem, it works anyway on certification environment. |
|
Back to top |
|
 |
Vitor |
Posted: Wed Dec 14, 2011 9:39 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
pjastrz wrote: |
Since we cannot reproduce it, we can't use modified client, with proper logging, to extract linked exception. Unless we can reproduce it, we cannot apply any patches, changes etc, because there is no way to verify it fixed problem, it works anyway on certification environment. |
In summary:
The production code doesn't record the linked exception so there's no real information on the problem. It works in the non-production environment so none of the diagnostic tools will tell you anything. You can't patch because you can't verify the patch is the soltution.
Well that certainly is a problem. Do let us know how you get on.
Seriously, all you have left now is to patch. Not to resolve the problem in any verifiable way but just because it's a good idea that might help. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
vmcgloin |
Posted: Wed Dec 14, 2011 3:02 pm Post subject: |
|
|
Knight
Joined: 04 Apr 2002 Posts: 560 Location: Scotland
|
You can produce a patch and verify that it produces the level of logging that will usefully help you resolve the problem quickly....
You can also as previously suggested review the maintenance available and make a strong case for some potential root causes...
It also sounds like you are not sure if what you are testing in non-production is the same setup as your production combination that has the error... Can you pursue that?
Only you know if this is a major problem for your business and how urgently you need to act. |
|
Back to top |
|
 |
|