MQ

  • 1.  Controlling MQPUT timeout

    Posted Fri July 30, 2021 10:26 AM
    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
    ------------------------------


  • 2.  RE: Controlling MQPUT timeout

    Posted Sun August 01, 2021 09:39 PM

    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
    ------------------------------



  • 3.  RE: Controlling MQPUT timeout

    Posted Mon August 02, 2021 09:49 AM
    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
    ------------------------------



  • 4.  RE: Controlling MQPUT timeout

    Posted Thu August 05, 2021 01:17 PM
    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
    ------------------------------



  • 5.  RE: Controlling MQPUT timeout

    Posted Tue August 10, 2021 09:35 AM
    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:

    1. Start MQ server
    2. Start MQ client (auto-reconnect enabled)
    3. Run MQPUT (works ok)
    4. Stop MQ server
    5. 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
    ------------------------------



  • 6.  RE: Controlling MQPUT timeout

    Posted Tue August 10, 2021 10:43 AM
    Hi Jim,

    When the channel is stopped the XMITQ is Get Inhibited, but Put Allowed.  So if you Put Disable the XMITQ you will receive a 2051 when you attempt to put to the Remote Queue.  If you put disable the Remote Queue you will get the 2051, but only for that application.  

    If you use an event handler and trap all the channel events, you can ensure that applications can only put to that queue when the supporting channel is active/running

    this eliminates the need to poll the channel status



    ------------------------------
    Glen Larson
    Lead Systems Engineer
    Progressive Insurance
    Colorado Springs CO
    ------------------------------



  • 7.  RE: Controlling MQPUT timeout

    Posted Tue August 10, 2021 03:15 PM

    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
    ------------------------------



  • 8.  RE: Controlling MQPUT timeout

    Posted Wed August 11, 2021 10:27 AM
    Morag,

         I misspoke.  We've tried several things.  First was the timeout wrapper.  The current code has auto-reconnect disabled as described.  I will look at the event listener as mentioned by you and Glen.

    Thanks,
    Jim

    ------------------------------
    Jim Creasman
    ------------------------------