Skip to main content

AMQ9202 Timeout of IBM WebSphere MQ connect takes too long -Middleware News

You are running WebSphere MQ on Solaris. You have two machines, one with a MQ client, and the other machine with a queue manager. You have a client application which checks to see if the queue manager is available, by doing a MQCONNX.

You have noticed a delay in the response from the MQCONNX. In the situation where the queue manager is stopped, your client receives a reason code 2059 MQRC_Q_MGR_NOT_AVAILABLE, but this is taking as long as 4 minutes.

Symptom

In the amqerr01.log of the client the following message is seen:

AMQ9202: Remote host '11.2.34.555 (1414)' not available, retry later.
EXPLANATION: The attempt to allocate a conversation using TCP/IP to host '12.3.45.678(1414)' was not successful. However the error may be a transitory one and it may be possible to successfully allocate a TCP/IP conversation later.
ACTION: Try the connection again later. If the failure persists, record the error values and contact your systems administrator. The return code from TCP/IP is 145 (X'91'). The reason for the failure may be that this host cannot reach the destination host. It may also be possible that the listening program at host '11.2.34.555 (1414)' was not running. If this is the case, perform the relevant operations to start the TCP/IP listening program, and try again.

Cause

When a client issues a MQCONNX to connect to a queue manager, this makes a tcpip connect() call. If the tcpip connect() can not complete because the remote host is not available, then it will eventually timeout and return a tcpip reason code x'91' (145, ETIMEDOUT).
The amount of time it takes for the timeout to occur is set by parameters in TCP/IP.

Resolving the problem

The Solaris ndd settable parameter tcp_ip_abort_cinterval defaults to a setting of 180000 milliseconds (3 minutes). Setting this to less than 1 minute allows the MQ channels to timeout in a shorter time interval. This applies to the case where the target node is removed from the network.
If you need assistance in changing the tcp_ip_abort_cinterval parameter, then you should consult your system administrator or Solaris support.

Note:
The corresponding Microsoft Windows registry parameters should be:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpMaxConnectRetransmissions
and
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\interface-name\TcpInitialRTT

Comments

adsrerrapop

Popular posts from this blog

IBM Websphere MQ interview Questions Part 5

MQ Series: - It is an IBM web sphere product which is evolved in 1990’s. MQ series does transportation from one point to other. It is an EAI tool (Middle ware) VERSIONS:-5.0, 5.1, 5.3, 6.0, 7.0(new version). The currently using version is 6.2 Note: – MQ series supports more than 35+ operating systems. It is platform Independent. For every OS we have different MQ series software’s. But the functionality of MQ series Default path for installing MQ series is:- C: programfiles\BM\clipse\SDK30 C: programfiles\IBM\WebsphereMQ After installation it will create a group and user. Some middleware technologies are Tibco, SAP XI. MQ series deals with two things, they are OBJECTS, SERVICES. In OBJECTS we have • QUEUES • CHANNELS • PROCESS • AUTHENTICATION • QUERY MANAGER. In SERVICES we have LISTENERS. Objects: – objects are used to handle the transactions with the help of services. QUEUE MANAGER maintains all the objects and services. QUEUE: – it is a database structure ...

IBM Websphere MQ Reason code list / mq reason codes / websphere mq error codes / mq error messages

Reason code list ================= The following is a list of reason codes, in numeric order, providing detailed information to help you understand them, including: * An explanation of the circumstances that have caused the code to be raised * The associated completion code * Suggested programmer actions in response to the code * 0 (0000) (RC0): MQRC_NONE * 900 (0384) (RC900): MQRC_APPL_FIRST * 999 (03E7) (RC999): MQRC_APPL_LAST * 2001 (07D1) (RC2001): MQRC_ALIAS_BASE_Q_TYPE_ERROR * 2002 (07D2) (RC2002): MQRC_ALREADY_CONNECTED * 2003 (07D3) (RC2003): MQRC_BACKED_OUT * 2004 (07D4) (RC2004): MQRC_BUFFER_ERROR * 2005 (07D5) (RC2005): MQRC_BUFFER_LENGTH_ERROR * 2006 (07D6) (RC2006): MQRC_CHAR_ATTR_LENGTH_ERROR * 2007 (07D7) (RC2007): MQRC_CHAR_ATTRS_ERROR * 2008 (07D8) (RC2008): MQRC_CHAR_ATTRS_TOO_SHORT * 2009 (07D9) (RC2009): MQRC_CONNECTION_BROKEN * 2010 (07DA) (RC2010): MQRC_DATA_LENGTH_ERROR * 2011 (07DB) (RC2011): MQRC_DYNAMIC_Q_NAME_ERROR * 2012 (07DC) (RC201...

Adding SSL certificates to a mixed z/OS and Unix queue manager environment - Middleware News

Adding SSL certificates to a mixed z/OS and Unix queue manager environment - Middleware News 1. Security Considerations IBM advises customers who are using SSL, that the most secure way to do this is to use recognized Certification Authorities to sign their certificates. Ensuring secure transfer of information is the main purpose of SSL. This integrity must be properly observed when setting up SSL. You should always be certain who has signed each of your SSL certificates, who has had and who continues to have access to them. The first secure way to generate certificates is to generate a certificate request, on each system or machine that uses SSL. This request has to be signed by an external Certification Authority before it can be used. Getting certificate requests signed by a CA is secure, because during the signing process at no point do any files contain the certificate's Private Keys. This principle is vital to SSL security. Signing certificates in this way is covered...