Details

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

      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.

        Issue Links

          Activity

          Hide
          Marcel Šebek
          added a comment -

          Source and .war of sample application

          Show
          Marcel Šebek
          added a comment - Source and .war of sample application
          Hide
          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
          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
          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
          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
          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
          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:
              Michael Musgrove
              Reporter:
              Marcel Šebek
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: