Home/ Questions/Q 7656081
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T12:40:38+00:00

On several occasions I have received the following error from a .Net (C#, 4.0)

  • 0

On several occasions I have received the following error from a .Net (C#, 4.0) application out of the blue on sending a message thru a producer:

CWSMQ0082E: Failed to send to CompCode: 2, Reason: 2009. A problem was encountered whilst sending a message. See the linked exception for more information.

Of course, the LinkedException (why not use the InnerException IBM???) is null i.e. no more information available.

Code I’m using (pretty straightforward):

var m = _session.CreateBytesMessage();
m.WriteBytes(mybytearray);

m.JMSReplyTo = myreplytoqueue;
m.SetIntProperty(XMSC.JMS_IBM_MSGTYPE, MQC.MQMT_DATAGRAM);

m.SetIntProperty(XMSC.JMS_IBM_REPORT_COA, MQC.MQRO_COD);
m.SetIntProperty(XMSC.JMS_IBM_REPORT_COD, MQC.MQRO_COA);

myproducer.Send(m, DeliveryMode.Persistent, mypriority, myttl);

(Offtopic: I hate the SetIntProperty way of setting properties. Which <expletive deleted> came up with that idea? It takes ages to look up all sorts of constants all over the place and its allowed values.)

The exception is thrown on the .Send method. I’m using XMS.Net (IA9H / 2.0.0.7). The only Google result that turns up turns out to have a different reason code (and even if it were the same, it should be fixed in my version if I understand correctly). This occurs randomly (though it seems to happen more often when it’s been a while since a message has been sent/received) and I have no way to reproduce this.

I have ab-so-lute-ly no idea how to troubleshoot this or even where to start looking. Is this something caused by the server-side? Is it caused by XMS.net or some underlying IBM WebSphere MQ infrastructure?

Some results that I found that seem similar are suggesting to set SHARECNV to any value higher than 0 or to “true” / “yes” but the documentation explicitly tells me the default is 10. Also; I have no idea if this is the cause so changing it to another value feels like a shotgun approach.

Anybody any idea on how to go about solving this? I could of course just catch the exception, tear everything (channels, sessions, whatever) down and restart but that’s just plain ugly IMHO.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The 2009 return code means “Connection Broken.” Basically, the underlying TCP socket is gone and the client finds out about it at the time of the API call. It is possible to tune the channels using heartbeat and keepalive so that WMQ tries harde to keep the socket alive. However if the socket is timed out by the underlying infrastructure, nothing WMQ can do will help. Examples we’ve seen are that firewalls and load balancers are often set to detect idle connections and sever them.

    Modern versions of WMQ client will attempt to reconnect transparently. The application just blocks a bit longer when this occurs.

    Short of using the automatic reconnect, the only solution is in fact to rebuild the connection. Since it will get a new connection handle, all the object handles must be rebuilt as well.

    Many of the tuning functions described here are available through the client configuration file, available in v7.0 and greater clients. In particular, the TCP stanza of that file enables keepalive. (The TCP spec says that if keepalive is provided, it must be disabled by default.) The QMgr has a similar ini file with configuration stanzas, including one for keepalive. The latest WMQ client is available as SupportPac MQC71 if you need that.

    • 0