Uploaded image for project: 'Application Server 3  4  5 and 6'
  1. Application Server 3 4 5 and 6
  2. JBAS-8124

Memory Leak in JBossMQ with 2PC QueueSessions

    XMLWordPrintable

Details

    • Bug
    • Resolution: Unresolved
    • Major
    • No Release
    • JBossAS-4.2.3.GA
    • JMS (JBossMQ)
    • None
    • Hide

      Create a QueueConnection and cache it.
      Create one or more transacted QueueSessions on it and send messages and close the QueueSession.
      Leaking TXState objects can be seen in map org.jboss.mq.SpyConnection#spyXAResourceManager#transactions

      Show
      Create a QueueConnection and cache it. Create one or more transacted QueueSessions on it and send messages and close the QueueSession. Leaking TXState objects can be seen in map org.jboss.mq.SpyConnection#spyXAResourceManager#transactions

    Description

      JBossMQ has a memory leak, which has the same symptoms as reported for JBoss Messaging in https://jira.jboss.org/browse/JBMESSAGING-638 and discussed in http://community.jboss.org/thread/128250.

      Problem is that when using a transacted QueueSession, when closing QueueSession#close invokes QueueSession#internalRollback to clean-up any unacknowledged messages, but also starts a new transaction, which is added to QueueConnection's SpyXAResourceProvider.
      Since this transaction is never committed or rolled-back, it stays for the lifetime of the QueueConnection, which can be like forever when cacheing the QueueConnection. Also see "Steps to Reproduce"
      Will attach MAT screenshot.

      This occurs in JBossMQ of 4.2.3, but also 4.0.5 (and probably all 4.x)
      I am aware of the EOL of JBoss 4.x, but will attach a proposed patch anyways.

      Possible workarounds:

      • Do not use transacted QueueSessions
      • Close and nullify the QueueConnection from time to time to let GC clean-up the leaked objects

      Attachments

        1. JBAS-8124.diff
          2 kB
        2. MAT.png
          MAT.png
          273 kB

        Activity

          People

            adrian.brock Adrian Brock (Inactive)
            r.neubauer@seeburger.de Rico Neubauer (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated: