MQ

 View Only
Expand all | Collapse all

Persistence of Transmit Queues

  • 1.  Persistence of Transmit Queues

    Posted Wed November 16, 2022 02:00 AM
    Hello,

    i hope someone may help us with our Question about the persistence of Transmit Queues. As Default Transmit Queues are defined "not persistent".
    Could it be usefull to define the Transmit Queues as persistent or are there any other side effects?

    What happens to messages in a Transmit Queue which defined as „not persistent" if the Server restarted during the messages are waiting for Transfer?

    Thanks and Regards

    ------------------------------
    Katja Meyer
    ------------------------------


  • 2.  RE: Persistence of Transmit Queues

    IBM Champion
    Posted Wed November 16, 2022 02:42 AM

    Hi Katja,

    The "Default Persistence" setting (MQSC keyword DEFPSIST) **ONLY** comes into play when an application puts a message to a queue and does not itself specify whether the message is persistent or non-persistent.

    This setting on a transmission queue would also only come into play if applications are not using a QREMOTE definition and are instead putting to queue@Qmgr. This can be the case for replying applications that use the ReplyToQ and ReplyToQMgr fields from the request message. However, I would also expect such applications to use the persistence from the request message.

    If you believe you have applications that are not setting the persistence of their messages, then changing the default persistence of the transmission queue could change the behaviour that these applications were previously experiencing.

    If you have non-persistent messages on a queue (whether they were made non-persistent deliberately by the application, or through the default persistence setting) then if you cycle the queue manager, those messages may be thrown away by the queue manager.

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------



  • 3.  RE: Persistence of Transmit Queues

    IBM Champion
    Posted Fri December 02, 2022 09:05 AM
    Edited by Francois Brandelik Fri December 02, 2022 09:05 AM
    Morag,

    I would have expected you to add a recommendation there like:
    Do not change the default persistence of the XMIT Queue, have the application set the persistence of the message.
    The default persistence of the queue does not change the persistence attribute set on the message.


    ------------------------------
    Francois Brandelik
    ------------------------------



  • 4.  RE: Persistence of Transmit Queues

    IBM Champion
    Posted Fri December 02, 2022 11:28 PM

    Hi FJ,

    I'm sorry to have disappointed you.

    I'm not sure whether the recommendation is entirely necessary, since, as my answer suggests, it would be rare for any application to actually end up making use of the default persistent value set on a transmission queue. An application written so simply that it cannot even manage to set the persistence of the message is unlikely to be doing a put to queue @ qmgr, and instead will be using a QREMOTE, and so will not use the XmitQ default persistence. Most applications that are doing a put to queue @ qmgr are probably replying to a request message, and so likely reuse the MQMD, and thus adopt the persistence of the request message - as you would hope that they would. This only leaves applications that are complex enough to be able to code a put to queue @ qmgr, but at the same time are not able to set the persistence of the message themselves. To me, this feels like a very small set of applications. The OP gave no suggestion that these were in play.

    It is always difficult to know just how much detail to go into about default persistence settings when a question mentions it. I tried to answer the question that was asked, but there is always an uncomfortable feeling that perhaps the OP does not fully understand the reason for and use of the default persistence setting. Perhaps we could do with a targeted blog post on just that subject to refer people to?

    Cheers,
    Morag

    ​​​

    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------



  • 5.  RE: Persistence of Transmit Queues

    Posted Mon December 05, 2022 01:33 AM
    Hey Morag,

    thank you for the extensive reply.
    The reason for our question are lost messages, though this was pretty much a shot in the dark with this one.
    To quickly outline the situation:

    We have messages that are being transmitted through multiple queuemanagers via alias queues through our cluster, which finally leads to a remote queue which is not under our administration. The receiving end told us about warnings, that our messages are not persistent.
    Our sending side and queues are all defined persistent, so are the messages itself, the only things not persistent are the transmitqueues in between.

    We personally do not believe that the messages were lost in our transmission but we're double checking every possible point of failure here.

    To specify the question:
    Are persistent messages also dropped when they are "parked" in a transmit queue and the queuemanager (rather the entire server) is restarted?

    Kind regards

    ------------------------------
    Sebastian Wilk
    ------------------------------



  • 6.  RE: Persistence of Transmit Queues

    Posted Mon December 05, 2022 02:58 AM

    Hi Sebastian,

    The persistence of a message is determined when it is first put, either through the application put options or the queue definition. Once the persistence has been established, it won't change as the message moves through the MQ network to the target queue.

    A persistent message will be retained on it's current queue if a qmgr is restarted, both for normal queues and xmit queues. Channel batch processing will ensure that persistent messages are retained across a channel failure as well. Even if there is an error putting the message to a target queue (e.g. the queue is full) MQ channels will retain the message. It will either be put to a dead letter queue or the channel will stop if no DLQ is available.

    Your problem description suggests two symptoms:

    1. The target application reporting non-persistent messages arriving on the target queue.
    2. Messages, which are believed to be persistent, being lost before they reach the target queue.

    Determining the cause of these two would require different approaches, as the available information is very different.

    1. For the first case, the content of the messages is your best source of information for getting closer to the problem. If the target application can capture details of the non-persistent messages, then you can use that to guide your investigation.
      The first thing to identify would be the source of the non-persistent messages. If your application is supposed to be putting persistent messages, then the non-persistent ones might be coming from another application using the wrong target queue. The MQMD fields (ReplyToQMgr, UserIdentifier, ApplIdentityData, ApplOriginData) may help with that. Depending on what the messages contain, the body may also help identify the source.
      If the messages are coming from your application, then I'd suggest seeing if there is a common pattern for the non-persistent messages compared to the persistent ones, as that would give clues to the circumstances which result in non-persistent messages.
    2. In the case of missing messages, there is less information to work with, which makes it a little more difficult to make progress. 
      First, I'd suggest confirming that the messages aren't still in the system. If you have checked that they aren't stuck on an xmit queue, the other destination I'd look at is the dead letter queues. Also check whether there are any DLQ handler applications which may have removed the messages from the DLQ.
      Another potential source of information is to determine exactly which messages are going missing. Is there any information captured by the application which would allow you to determine which messages arrive correctly and which ones are lost?
      If neither of these help, then you may need to introduce some diagnostic information to track the messages. MQ provides a couple of message route tracking techniques which may help: Activity Recording and Trace-route Messaging. See this section of the MQ documentation for details.


    ------------------------------
    Doug Burns
    ------------------------------



  • 7.  RE: Persistence of Transmit Queues

    Posted Mon December 05, 2022 04:02 AM
    Hey Doug,

    thank you for your input.
    The question was deliberately without more detail to avoid the full circle jerk (and I mean that in a positive way here) around possible problems.

    To clarify a few things:
    We have multiple monitors on said route as well as a statistic.
    We habe checked DLQs, Transmitqueues and all other possible backouts/places where messages could have been "lost" for various reasons.
    We also checked server logs for possible unscheduled restarts or outtages, including client logs on applications.
    Our receiver also provided some logs which state no failures or outtages on there part either.

    We brushed through all points involved in the process without finding any trace of errors/accumulations of messages or any other occurence that could explain our situation here.

    The only strange thing we have not fully covered yet was the non persistent message thing, but as I mentioned before, that was pretty much a shot in the dark as we very much doubt that we "lost" messages without any possible trace.
    But in order to make sure, we wanted to clarify that our understanding reflects how MQ actually works.

    TL;DR
    If the messages are persistent, they will survive a Queuemanager/Serverrestart, even if they reside in a non-persistent queue.
    Thank y'all for your time 🙂

    ------------------------------
    Sebastian Wilk
    ------------------------------



  • 8.  RE: Persistence of Transmit Queues

    IBM Champion
    Posted Tue December 06, 2022 03:26 AM
    Following on from Doug's comments, it feels like you need to know if messages are being created as non persistent.
    You can use statistics to display the number  of persistent, and the number of non persistent messages put to a queue.   The statistics data should not be too voluminous
    Once you have found a queue where there is a mixture of persistent and non persistent messages, you can use accounting to see which applications put to the queue - and for the applications which put a mixture you can then go to the program source and find out why.
    You can get a lot of data with accounting... so collecting it for a 1 minute duration, and analysing that, then sample again may be an option.

    Often messages  on a queue are all the same persistence.  There are some scenarios where there is a mixture, and you need to understand which are valid and which are not.

    Colin

    ------------------------------
    Colin Paice
    ------------------------------



  • 9.  RE: Persistence of Transmit Queues

    IBM Champion
    Posted Thu December 01, 2022 11:59 AM
    It would be nice to keep message persistent; Side effects: if a high volume application is writing to the queue; then u will notice some performance and IO issue; as the msg needs to be committed before read.

    ------------------------------
    om prakash
    ------------------------------



  • 10.  RE: Persistence of Transmit Queues

    IBM Champion
    Posted Mon December 05, 2022 08:12 AM
    Hi Sebastien,

    Please remember that if the message is not persistent, if there is a network hickup in the channel, the message may be lost in the channel.
    A persistent message would put the channel in retry, even if it is for a very brief moment. A non persistent message can be dropped.
    Running dspmqrte may tell you where the message is disappearing... that is if there is a default return route...

    Hope it helps

    ------------------------------
    Francois Brandelik
    ------------------------------



  • 11.  RE: Persistence of Transmit Queues

    Posted Thu December 08, 2022 07:34 AM
    This behaviour depends upon the NPMSPEED option. Even non-persistent messages will survive a channel/network failure when configured to do so.

    ------------------------------
    Andrew Hickson
    ------------------------------