ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » Issue receiving messages via MQ in a certain environment

Post new topic  Reply to topic
 Issue receiving messages via MQ in a certain environment « View previous topic :: View next topic » 
Author Message
OliverReeves
PostPosted: Mon Jan 18, 2010 4:57 pm    Post subject: Issue receiving messages via MQ in a certain environment Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Mon Jan 18, 2010 7:17 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
OliverReeves
PostPosted: Mon Jan 18, 2010 7:35 pm    Post subject: Reply with quote

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
View user's profile Send private message
zonko
PostPosted: Mon Jan 18, 2010 11:12 pm    Post subject: Reply with quote

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
View user's profile Send private message
OliverReeves
PostPosted: Tue Jan 19, 2010 2:19 pm    Post subject: Reply with quote

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
View user's profile Send private message
OliverReeves
PostPosted: Wed Jan 20, 2010 2:25 pm    Post subject: Problem resolved Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » Issue receiving messages via MQ in a certain environment
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.