Uploaded image for project: 'AMQ Broker'
  1. AMQ Broker
  2. ENTMQBR-3019

Aborted transactions cause page file retention

    XMLWordPrintable

Details

    • Bug
    • Resolution: Cannot Reproduce
    • Critical
    • None
    • AMQ 7.4.0.GA, AMQ 7.5.0.GA
    • broker-core, journal
    • None
    • Hide
      • Configure an OOTB broker with a global-max-size (I used 100mb).
      • Start a producer and produce a large number of messages (I used 100k - 500k 30kb messages) to force significant paging
      • After producer is finished, note the paging directory usage, then connect a transacted consumer that is either configured with a short transaction timeout (and fails to commit the session) or throws an exception before commiting the session.
      • As the redeliveries are exhausted and messages move to DLQ, paging usage increases until it is nearly double the previous mark
      • When all messages are moved into the DLQ, paging usage remains high - even if consumers are disconnected. Restarting the broker does not clean up the paging directory and purging the DLQ may only partially clean it up.
      Show
      Configure an OOTB broker with a global-max-size (I used 100mb). Start a producer and produce a large number of messages (I used 100k - 500k 30kb messages) to force significant paging After producer is finished, note the paging directory usage, then connect a transacted consumer that is either configured with a short transaction timeout (and fails to commit the session) or throws an exception before commiting the session. As the redeliveries are exhausted and messages move to DLQ, paging usage increases until it is nearly double the previous mark When all messages are moved into the DLQ, paging usage remains high - even if consumers are disconnected. Restarting the broker does not clean up the paging directory and purging the DLQ may only partially clean it up.

    Description

      If I produce a large number of messages to the broker, allowing them to be paged out, then fire up a transacted consumer that aborts the transaction before committing, I see the messages correctly moved into the DLQ. However, in several times testing, what I have seen is that page file usage grows to double its previous usage and is not always cleaned up - even if no more messages remain in the original queue.

      For example, if I produce 30GB of messages, the paging directory predictably consumes 30GB of disk. If I then fire up a consumer that fails to commit, but instead aborts the session, the messages are moved into the DLQ. While this is occurring, the paging directory usage grows from 30 to nearly 60GB. In most of my tests, even after the messages were all moved into the DLQ, the paging directory was not cleaned up and continued to consume 60GB. In these cases, Even after stopping the consumers, the files remained, and they also remained after restarting the broker. Even after purging the DLQ, I am seeing several GB occupied by the paging directory with 0 messages in all addresses.

      Expectation: I would expect paging volume usage to drop to previous levels after all messages are moved from the original destination to DLQ

      Attachments

        Activity

          People

            Unassigned Unassigned
            rhn-support-dhawkins Duane Hawkins
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: