Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Duplicate Issue
    • Affects Version/s: 7.1.1.Final
    • Fix Version/s: None
    • Component/s: Transactions
    • Labels:
      None
    • Environment:

      Description

      I'm experiencing problems with XA datasources on jboss 7 and postgres database. The test application periodically (each 5 seconds) performs several JPA queries. I use @Schedule facility on @Singleton @Startup bean. However, after a few days, the server runs out of memory. Switching to local tx datasources seems to fix the problem. Analysis of heap dump using visualvm gives the following:

      Heap is quite full (~490 MB from 512MB), most space is taken by byte[] (40%, 200MB) and HashMap.Entry (16%, 80MB) objects, so that gives no much information. Computing retained sizes shows that most space (but just ~16MB) is taken by com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule#1. Further analysis shows that XARecoveryModule._xidScans contains ~8000 entries. The size continuously grows. When the dump is taken before the OOM conditions starts, eg. when the heap is 50% full, the size of this hashmap is ~4000, so it looks like it grows continuously.

      I will attach my example test case.

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            sebek64 Marcel Šebek added a comment -

            Source and .war of sample application

            Show
            sebek64 Marcel Šebek added a comment - Source and .war of sample application
            Hide
            mmusgrov Michael Musgrove added a comment -

            The related issue JBTM-1183 looks like a configuration issue. Please can you apply the resolution mentioned in that JIRA (specify the recovery plugin) and retest.

            Show
            mmusgrov Michael Musgrove added a comment - The related issue JBTM-1183 looks like a configuration issue. Please can you apply the resolution mentioned in that JIRA (specify the recovery plugin) and retest.
            Hide
            sebek64 Marcel Šebek added a comment -

            Yes, the solution mentioned in JBTM-1183 seems to fix the problem. The heap is no longer growing and xidScans contains constant number of elements. The fix is however not supported by jboss 7.1.1.Final, because it includes old ironjacamar. I've built git revision 91711195ffb97d63200390e4eca18fd9e1d8b1a6.

            Show
            sebek64 Marcel Šebek added a comment - Yes, the solution mentioned in JBTM-1183 seems to fix the problem. The heap is no longer growing and xidScans contains constant number of elements. The fix is however not supported by jboss 7.1.1.Final, because it includes old ironjacamar. I've built git revision 91711195ffb97d63200390e4eca18fd9e1d8b1a6.
            Hide
            sebek64 Marcel Šebek added a comment -

            Now after a few days the heap usage is still low, so I can confirm that the only cause of the problem is missing recovery plugin in the configuration of xa datasource. Because of this, we can consider this issue a duplicate of JBTM-1183.

            Show
            sebek64 Marcel Šebek added a comment - Now after a few days the heap usage is still low, so I can confirm that the only cause of the problem is missing recovery plugin in the configuration of xa datasource. Because of this, we can consider this issue a duplicate of JBTM-1183 .

              People

              • Assignee:
                mmusgrov Michael Musgrove
                Reporter:
                sebek64 Marcel Šebek
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Development