1 Reply Latest reply on Aug 9, 2004 1:56 PM by genman

    Memory and QueueSession.commit

    animaal

      Hi,

      Apologies if this is the incorrect forum.

      I'm having trouble with OutOfMemory problems with my app. I'm hoping something below might help somebody tell me what I'm doing wrong...

      My environment :
      Redhat Linux 9 (also tried Solaris)
      JBoss 3.2.1 (I'd rather not upgrade it unless absolutely necesssary)
      Default HSQL JMS storage (also tried MySQL, but no improvement).

      I have a servlet sending JMS messages to a queue, then those messages are consumed by an MDB.

      I ran a smaller test under OptimizeIt Pro, sending 1500 messages, and them being consumed by the MDB. Everything runs normally. However, after completion, I notice there are still 1500 instances of "org.jboss.mq.SpyXAResourceManager$TXState" taking up memory.

      They are listed in Optimizeit Pro, here is a typical example :
      org.jboss.mq.SpyXAResourceManager$TXState@12fcee1{ txState=0, sendMessages=[], ackedMessages=[] }

      This is the stacktrace for their allocation:

      SpyXAResourceManager.startTX() (SpyXAResourceManager.java:246)
      SpySession.rollback() (SpySession.java:485)
      SpySession.close() (SpySession.java:367)
      MyBean.onMessage() (MyBean.java:101)
      GeneratedMethodAccessor81.invoke() ()
      etc...

      During the running of the test, 15 instances of my MDB were created.

      This is the code I am using in my MDB to close the transaction:

      qsession.commit();
      qsession.close();
      qsession = null;


      Can anybody tell me if it's normal for those objects to remain in memory after finishing their work? Is there any particular stupid thing I'm likely to be doing wrong?

      Many Thanks,
      John.

        • 1. Re: Memory and QueueSession.commit
          genman


          If you're using an MDB, you don't need to create a QueueSession. What does your MDB do?

          You might want to test using JBoss 3.2.5 as a baseline. If it works, it's a JBoss bug. If it doesn't, submit a test case.