|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Issue receiving messages via MQ in a certain environment |
« View previous topic :: View next topic » |
Author |
Message
|
OliverReeves |
Posted: Mon Jan 18, 2010 4:57 pm Post subject: Issue receiving messages via MQ in a certain environment |
|
|
Newbie
Joined: 18 Jan 2010 Posts: 4
|
Hi all,
I'm currently involved in a project which is using MQ at the back-end. We have to communicate with many systems via this mechanism and, previouskly, we have done successfully using a custom C++ component which does the communication for us.
This new project requires a new approach to be taken (for reasons I won't go into here) and we are using a custom-written WCF transport component which talks to MQ via the managed libraries that come with the MQ client install.
On the developer machines we are able to successfully connect to the queues and send/receive messages without any problems.
On our test server, we are having intermittant problems with receiving messgaes from the same queues.
Before I go on here, are some details on the environments:
Application Details
- Web application using ASP.NET MVC 2 RC
- CLR v2.0, .NET 3.5
- Runs under IIS 7
Developer Machines
- Windows 7 x64
- MQ Client 7.0.1.0
Test Environment
- Windows Server 2008 x64
- MQ Client 7.0.1.0
When we first started developing the new transport layer to talk to MQ, we were able to run it in Dev but not in Test. We then realised that we had to set the NMQ_MQ_LIB environment variable to managed when setting the MQC.TRANSPORT_PROPERTY to MQC.TRANSPORT_MQSERIES_MANAGED in code. This seemed to solve the problem, and for an entire day, the test environment worked perfectly. At the end of yesterday, we started getting errors again.
FDC files were generated both on the Client side and on the server side. The server indicates a major error of rrcE_BAD_DATA_RECEIVED, while the client side's major error is 0x20009504. I have those FDC files handy, but I didn't want to paste them in here in case it was considered bad manners. Please let me know where I should put them for access.
I don't have the ability to change anything on the server, but the client is completely under my control.
I have no idea where to go on this. Would it be possible to get any insights into this issue? Why would the clients behave so differently across different environments? I'm happy to share the FDC files if required.
Thank you for any help you can provide.
Kind regards
Oliver. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Jan 18, 2010 7:17 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Have you googled the probeId on the FDC files?
Have you searched the IBM site for the probeId?
What was the result?  _________________ MQ & Broker admin |
|
Back to top |
|
 |
OliverReeves |
Posted: Mon Jan 18, 2010 7:35 pm Post subject: |
|
|
Newbie
Joined: 18 Jan 2010 Posts: 4
|
Thanks for the reply.
On the client FDC, the probe IDs are DN153001, DN144001 and DN140001, which according to IBM indicate an issue with xcsCOMP_MSDNET/.Net Bindings Support. I can't find any details at all regarding the numbers. I have googled for the IDs and found nothing. Same goes for the IBM site.
The server side error log looks like this:
Code: |
19.01.10 09:28:38 - Process(745614.3157) User(username) Program(amqrmppa)
AMQ9207: The data received from host 'CLNTNAME (xxx.xxx.xxx.xxx)' is not valid.
EXPLANATION:
Incorrect data format received from host 'CLNTNAME (xxx.xxx.xxx.xxx)' over
TCP/IP. It may be that an unknown host is attempting to send data. An FFST file
has been generated containing the invalid data received.
ACTION:
Tell the systems administrator.
----- amqxfdcx.c : 768 --------------------------------------------------------
19.01.10 09:28:38 - Process(745614.3157) User(username) Program(amqrmppa)
AMQ6184: An internal WebSphere MQ error has occurred on queue manager SRVNAME.
EXPLANATION:
An error has been detected, and the WebSphere MQ error recording routine has
been called. The failing process is process 745614.
ACTION:
Use the standard facilities supplied with your system to record the problem
identifier, and to save the generated output files. Contact your IBM support
center. Do not discard these files until the problem has been resolved.
----- amqxfdcx.c : 807 -------------------------------------------------------- |
This doesn't help too much, but I thought I'd share in case.
The server-side FDC indicates Probe ID CO052000, which apparently has something to do with Communications. The Major Error Code, as mentioned before, is rrcE_BAD_DATA_RECEIVED. This page gave some details but didn't help me too much. The exact same binaries behave perfectly on the dev machines, but not on the test machine. They reference the same queues on the same server. The first thing that we looked at was the possibility of sending incorrect data, but the packets/payloads are exactly the same.
Also, the FDC indicates that writing to the queues works just fine, but the response it what seems to cause the problem as it's the call to MQQueue.Get() which results in the error.
One thing I have noticed is that the client's addressing mode is 32-bit and the servers is 64-bit. Would that cause problems?
Should I upload the FDCs somewhere?
Thanks again for the response.
Oliver. |
|
Back to top |
|
 |
zonko |
Posted: Mon Jan 18, 2010 11:12 pm Post subject: |
|
|
Voyager
Joined: 04 Nov 2009 Posts: 78
|
This FFST is produced either when a data segment arrives which does not contain the correct header (TSH ) for the WMQ protocol, or the data in the header does not correspond to what the client was expecting. In your case, it is probably the latter.
The FFST has a dump of the data that was actually received. Your best bet is to contact IBM with the error description and sed them the FDCs. |
|
Back to top |
|
 |
OliverReeves |
Posted: Tue Jan 19, 2010 2:19 pm Post subject: |
|
|
Newbie
Joined: 18 Jan 2010 Posts: 4
|
Thanks for your response. We've since submitted the details to IBM. Let's hope they come back with something.
Cheers
OJ |
|
Back to top |
|
 |
OliverReeves |
Posted: Wed Jan 20, 2010 2:25 pm Post subject: Problem resolved |
|
|
Newbie
Joined: 18 Jan 2010 Posts: 4
|
Hi all,
I just thought i'd let you know that we have managed to resolve the problem.
I found out yesterday that our Queue Managers are actually load-balanced across two servers. After a bit of investigation, I managed to determine that the two Queue Managers were running different versions of MQ. The load-balancer uses sticky-sessions which is why it would always happen in one environment, but not in another.
The protocol error issue was because a client was connecting to a server running an older version.
Thanks to all who responded. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|