MQ

MQ

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  Message Expiry vs Queue-Level Retention - Need help

    Posted 14 hours ago

    I have an IBM MQ queue configured with MAXDEPTH(50000).
    The consuming application processes messages but only needs data that's less than 30 minutes old - anything older becomes irrelevant for processing.

    I'm exploring if MQ can automatically handle message cleanup in such cases.

    I'm aware that IBM MQ has no native queue-level TTL (time-to-live) setting for messages, and that expiry is typically handled at the message level via the MQMD.Expiry field.

    Questions:
    1️⃣ Can IBM MQ automatically delete or expire messages that are older than 30 minutes?
    2️⃣ Is there any way to set a 1-day retention period on the queue itself so that messages get automatically deleted after 24 hours, without modifying the producer or application code?

    Appreciate your time. Looking forward to hearing some solution. 



    ------------------------------
    Rashmitha Thukuntla
    ------------------------------


  • 2.  RE: Message Expiry vs Queue-Level Retention - Need help

    Posted 8 hours ago

    Hi Rashmitha,

    I think you were almost there with your research already.

    You are quite right that messages can have an TTL (time-to-live) set using the MQMD.Expiry field. 

    When a message has a TTL set, the queue manager will automatically delete (aka expire) messages whose TTL has passed.

    You can set the TTL of a message, either in the application directly, or though a queue attribute called CAPEXPRY (note - no letter 'i' in the name)

    The queue attribute means that you can do this without modifying the application code.

    To set a 30 minute TTL with the queue attribute you would use CAPEXPRY(18000) - i.e. this value is configured in 10ths of a second.

    To set a 1 day TTL with the queue attribute you would use CAPEXPRY(864000)

    In case it is not obvious, you cannot have both of these set on the same queue.

    Also note that only new messages that are put into the queue after the change in CAPEXPRY make use of it.

    Here is some extra reading material about CAPEXPRY

    Cheers,
    Morag



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

    Original Message


  • 3.  RE: Message Expiry vs Queue-Level Retention - Need help

    Posted 3 hours ago

    >>> I'm exploring if MQ can automatically handle message cleanup in such cases

    Have you looked at CAPEXPRY ?

     

     

    Regards – Grant.

     

    In theory, there's no difference between theory and practice. In practice, there is.

     

    Worry more about your character than your reputation.  Character is what you are, reputation merely what others think you are. - John Wooden

     


    DTCC Internal (Green)

    DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. Message content created by DTCC is automatically secured using Transport Layer Security (TLS) encryption and will be encrypted and sent through a secure transmission connection if the recipient's system is configured to support TLS on the incoming email gateway. If there is no TLS configured or the encryption certificate is invalid on the recipient's system, the email communication will be sent through an unencrypted channel. Organizations communicating with DTCC should be using TLS v1.2 or newer to ensure continuation of encrypted communications. DTCC will not be responsible for any disclosure of private information or any related security incident resulting from an organization's inability to receive secure electronic communications through the current version of TLS.



    Original Message


Related Content