IBM Support

IT27271: Messages build up on SYSTEM.MQTT.PERSISTENT.STATE queue with multiple MQTT client takeovers in a short time period

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.


APAR status

  • Closed as program error.

Error description

  • When a large number of MQTT client takeovers are done for a
    single client id in a very short time period, there is a buildup
    of messages on the SYSTEM.MQTT.PERSISTENT.STATE queue.

Local fix

Problem summary

  • ****************************************************************
    This issue affects users of IBM MQ Telemetry service performing
    multiple takeovers of MQTT client connections in a short period
    of time, where those client connections all specify "clean
    session = true" in their connect options
    Platforms affected:
    Windows, Linux on x86-64, AIX
    When a MQTT client connects to the IBM MQ queue manager's
    Telemetry service, specifying "clean session = true" in the
    connect options, a "clean session record" message is put to the
    SYSTEM.MQTT.PERSISTENT.STATE queue. This message is used to
    ensure that when this client disconnects, all of its state is
    cleared up. If this client's state is taken over (by another
    client connecting and specifying the same client id as this
    existing client), then the taken-over session's clean session
    record message is removed from the SYSTEM.MQTT.PERSISTENT.STATE
    queue. If the newly-connecting client taking over this session
    has specified "clean session = true", a new clean session record
    message is put to that queue.
    If there are a number of client takeovers done in quick
    succession, this can result in one thread putting a clean
    session record to the SYSTEM.MQTT.PERSISTENT.STATE queue for one
    client instance, and this message being removed almost
    immediately afterwards by another thread on behalf of another
    client taking over the other client's session.
    If the time interval between a clean session record message
    being put to the SYSTEM.MQTT.PERSISTENT.STATE queue, and an
    attempt to remove that message, was very short, it was possible
    for the attempt to remove the message to fail, as the message
    had not been completely committed to the queue by this point. If
    this happened, the message would remain on the queue, and the
    taking-over client would put its own clean session record to the
    queue as well. The original message would not be removed from
    the queue. If there were a lot of client takeovers like this, in
    very quick succession, this could lead to a buildup of message

Problem conclusion

  • There is now no buildup of messages on the persistent state
    queue - there is only one clean session record per connected
    client specifying "clean session = true", which is removed when
    that client disconnects. If a client's state is taken over by a
    new connection with the same client id, the taken-over client's
    clean session record message on the persistent state queue is
    always removed, and a new message is put for the new connection.
    The fix is targeted for delivery in the following PTFs:
    Version    Maintenance Level
    v9.0 LTS
    v9.1 CD    9.1.3
    v9.1 LTS
    The latest available maintenance can be obtained from
    'WebSphere MQ Recommended Fixes'
    If the maintenance level is not yet available information on
    its planned availability can be found in 'WebSphere MQ
    Planned Maintenance Release Dates'

Temporary fix


APAR Information

  • APAR number


  • Reported component name


  • Reported component ID


  • Reported release


  • Status


  • PE




  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date


  • Closed date


  • Last modified date


  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name


  • Fixed component ID


Applicable component levels

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
12 March 2019