So this post finally answers the question about why your MQPUT is taking a long time. You have auto-reconnect enabled which is designed to ensure that the MQRC_CONNECTION_BROKEN return is not returned back to the caller of the MQPUT and instead it waits and remakes the connection and ensure the MQPUT is done successfully before returning. If you want to be notified immediately of the failure of the connection, you should turn off auto-reconnect and catch the return codes that it handles, yourself.
Auto-reconnect was designed for applications that are simple and can't cope with catching and handling non-zero return codes. Your application sounds like it is not only capable, but is expecting to do so.
You say that you have gotten around the extended period by disabling auto-reconnect. Could you say why you still need a timer around the MQPUT at this point? Is this the MQPUT that detects the failure of the connection? Are we now into the realms of how fast the client can detect the outage of the socket?
If you do use auto-reconnect, which I don't think you need to, you can use the event listener to tell you when the connection has gone.
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website:
https://www.mqgem.com------------------------------
Original Message:
Sent: Tue August 10, 2021 09:34 AM
From: Jim Creasman
Subject: Controlling MQPUT timeout
Glen,
Maybe I'm missing something but wouldn't the connection/channel need to be available in order to enable "PUT inhibit"? The scenario we're working through is this:
- Start MQ server
- Start MQ client (auto-reconnect enabled)
- Run MQPUT (works ok)
- Stop MQ server
- Run MQPUT (hangs indefinitely until server is back up)
What we want to happen is either for the second MQPUT to time out quickly, or to be notified via event before the second call is made that the connection is down. The trigger that is putting messages on the queue is a POST to the REST API of the service. If the channel is temporarily unavailable we can simply fail the POST.
We have gotten around this by disabling auto-reconnect and putting a timer around the MQPUT. We then stop and restart a connection if it times out. During this time (timeout to channel restarted) our client fails any POSTs that arrive. We recognize this is an edge case but it will happen occasionally. It would be convenient if the IBM MQ client provided for status events as some queuing clients do so the code could monitor this.
Jim
------------------------------
Jim Creasman
Original Message:
Sent: Thu August 05, 2021 01:17 PM
From: Glen Larson
Subject: Controlling MQPUT timeout
Hello Jim,
Assuming your have an event handler. A simple solution would be to have the event handler put inhibit the queue while the channel is down and enable it when the channel is started and becomes active. Of course your application would need to handle the 2051 Return Code: MQRC_PUT_INHIBITED.
------------------------------
Glen Larson
Lead Systems Engineer
Progressive Insurance
Colorado Springs CO
(719) 432-1360
Original Message:
Sent: Mon August 02, 2021 09:49 AM
From: Jim Creasman
Subject: Controlling MQPUT timeout
Morag,
Thanks for the info. We are not experiencing MQPUT problems. The scenario is one where are are hardening our systems and creating an artificial outage. In this use case we want the MQPUT behavior to be "fire-and-forget-about-it". The message being sent isn't critical and we don't want the client waiting an extended time due to an underlying connection issue. The MQPMO_ASYNC_RESPONSE seems promising. We'll look into that option.
By persistent connections I was referring to the auto-reconnect feature where if a connection is broken, then the client is notified and automatically retries until it's re-established (or eventually times out). Being notified when the connection status changes (e.g., connected --> retry) would allow us to hold off on MQPUT until it's working again.
Jim
------------------------------
Jim Creasman
Original Message:
Sent: Sun August 01, 2021 09:39 PM
From: Morag Hughson
Subject: Controlling MQPUT timeout
It is not normal for an MQPUT call to take very long. This is why it doesn't have a timeout. Do you know why your MQPUT calls are taking several seconds? it might be worth digging into that rather than trying to work around it by trying to have a timeout in the application. If you don't care whether the put works or not and want to have a true "Fire and Forget" so that you don't have to wait for the network line turn-around to send back the return code, you could look into MQPMO_ASYNC_RESPONSE.
If you lower the HBINT on the channel (at both ends) then this will mean the MQGET calls will wake up to send a heartbeat flow ore frequently.
What are "persistent connections"?
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
Original Message:
Sent: Fri July 30, 2021 10:26 AM
From: Jim Creasman
Subject: Controlling MQPUT timeout
Is there a way to set the timeout when performing an MQPUT call? My understanding is this is controlled by the HBINT value on the channel and there are no ways to set this either on the MQPUT or in the message header. We have a client application (using NodeJS MQ client) where we want to attempt the MQPUT but then have it fail if the put is not successful within a few seconds (much less than the default timeout).
If I lower the HBINT value on the channel, how does this affect an MQGET that is using the same channel? Should I define separate channels for PUT and GET to avoid any issues? We currently have the channel defined for persistent connections as follows:
DEFINE CHANNEL('CLNT.QC1') CHLTYPE(SVRCONN) SHARECNV(1) REPLACE
Related to this... is there a way to listen for connection events using the NodeJS MQ client? This would keep us informed of what is happening with the connection so when something like a restart of the MQ server occurs, the client could know to hold off on any PUTs until it was back up.
Thanks,
Jim
------------------------------
Jim Creasman
------------------------------