ibm-messaging / mq-mqi-nodejs

Calling IBM MQ from Node.js - a JavaScript MQI wrapper
Apache License 2.0
79 stars 42 forks source link

Found CONNX: MQCC = MQCC_FAILED [2] MQRC = MQRC_HOST_NOT_AVAILABLE [2538] ERROR in our Production only. #168

Closed JonnyyJ closed 1 year ago

JonnyyJ commented 1 year ago

Please include the following information in your ticket.

// const { mqGet } = require('./utils/promise-wrappers');

// eslint-disable-next-line prefer-destructuring const MQC = mq.MQC; const logger = getConsoleLogger(); /*

const listenerSubject = new Subject();

// assign param for listener const mqc = mq.MQC; const connectionOptions = new mq.MQCNO(); const connectionDetails = new mq.MQCD(); const connectionSecurity = new mq.MQCSP();

connectionDetails.ConnectionName = getProperty('IBMMQ.connectionName'); connectionDetails.ChannelName = getProperty('IBMMQ.channelName');

if (getProperty('IBMMQ.password')) { connectionSecurity.UserId = getProperty('IBMMQ.userId'); connectionSecurity.Password = null || getProperty('IBMMQ.password'); }

connectionOptions.SecurityParms = connectionSecurity; connectionOptions.Options |= mqc.MQCNO_CLIENT_BINDING; connectionOptions.ClientConn = connectionDetails;

/*

function getCB(err, hObj, gmo, messageDetails, buf, hConn) { // If there is an error, prepare to exit by setting the ok flag to false. if (err) { if (err.mqrc == MQC.MQRC_NO_MSG_AVAILABLE) { logger.info("No more messages available."); } else { logger.info(err); } ok = false; // We don't need any more messages delivered, so cause the // callback to be deleted after this one has completed. mq.GetDone(hObj); } else { if (messageDetails.Format == "MQSTR") { logger.info(Received message: ${buf}); listenerSubject.next(buf.toString()); } else { logger.info("binary message: " + buf); } } } function hexToBytes(hex) { for (var bytes = [], c = 0; c < hex.length; c += 2) bytes.push(parseInt(hex.substr(c, 2), 16)); return bytes; } /**

/*

module.exports = listenerClosure;


**Publisher:**

const { getConsoleLogger } = require('@xxx/utils/logger'); const mq = require('ibmmq'); const { getProperty } = require('@xxx/utils/properties'); const { mqPut } = require('./utils/promise-wrappers'); const { cleanUp } = require('./utils/clean-up')

const logger = getConsoleLogger(); // eslint-disable-next-line prefer-destructuring const MQC = mq.MQC; /*

module.exports = publisherClosure;



We want to locate whether this is an environment issue or a code issue, any thoughts?
ibmmqmet commented 1 year ago

Can't see anything obviously wrong. There might be additional diagnostics in the client and qmgr error logs (and perhaps even FDC files). There are many reasons for a 2538, mostly to do with network failures or timeouts in waiting for responses. Though I worry when I see a comment like "recursively calls itself" as it can imply all kinds of resources being exhausted if they are not being cleaned up. for example, reaching max number of sockets in a process.

JonnyyJ commented 1 year ago

Can't see anything obviously wrong. There might be additional diagnostics in the client and qmgr error logs (and perhaps even FDC files). There are many reasons for a 2538, mostly to do with network failures or timeouts in waiting for responses. Though I worry when I see a comment like "recursively calls itself" as it can imply all kinds of resources being exhausted if they are not being cleaned up. for example, reaching max number of sockets in a process.

Thanks for reaching out, the comment of "recursively calls" is a miss type, I just deleted that, sorry for the confusion. Also 2538 is the only error we are seeing, do you know where can we check the FDC files?

ibmmqmet commented 1 year ago

Error logs and FDCs can usually be found under /var/mqm/errors or $HOME/IBM/MQ/data/errors

JonnyyJ commented 1 year ago

Hi @ibmmqmet We cannot find any errors folder that you mentioned on our client side and we are using Linux. The service is deployed in a container, should we enable a sort of debug mode to generate the error logs? Also, our network guy is telling us this is not a network issue itself, since we didn't find any connection issue besides the RST packet, and they are saying it could be more like a session timeout or reaching to max session issue because each time we restart the service, the connection will come back about 1 hour. Is it possible that upgrading to the latest version could solve this issue? BTW we are still using Node 14 which is EOL and we are planning to upgrade to 18 in our next release.

Also, we are using the same channel for our Prod and non-prod QM, I see the docs mentioned that the default available sessions are 100, is it possible we already reached the max sessions and refuse to do the incoming request?

ibmmqmet commented 1 year ago

The MQ client error log directories ought to be SOMEWHERE in your environment. Perhaps under the root directory / in some container setups. There's no debug option - error logs are always generated by the client when needed.

And you also need to check the queue manager error logs to see if anything is mentioned there. Monitoring the queue manager channel status would also show if you are building up connections.

JonnyyJ commented 1 year ago

Thanks for the suggestion, we also did an update for the ibmmq sdk to the latest one and also update the node version from 14 to 18, after that the network error is magically gone, I will continue monitoring for few days, for now I will close this ticket.