[jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation

[Martin Gysel (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------


hi howard, thanks for your feedback. i changed the queue defs as follows:

<mbean code="org.jboss.jms.server.destination.QueueService"
      name="jboss.messaging.destination:service=Queue,name=testQueue"
      xmbean-dd="xmdesc/Queue-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends>jboss.messaging:service=PostOffice</depends>
      <attribute name="MaxDeliveryAttempts">10</attribute>
      <attribute name="FullSize">200</attribute>
      <attribute name="PageSize">100</attribute>
      <attribute name="DownCacheSize">100</attribute>
      <attribute name="SecurityConfig">
         <security>
            <role name="guest" read="true" write="true"/>
            <role name="publisher" read="true" write="true" create="false"/>
            <role name="noacc" read="false" write="false" create="false"/>
         </security>
      </attribute>
   </mbean>

the test case with 100K messages should now occupy a max of about 20MB (200 x 100K). before running the test again i changed the test program to adapt as realistic as possible to our current application logic. so the loop now takes place in the main() method and in the receiving of the messages (MaxDeliveryAttempts set to 10). there is no commit() operation anymore ( see the attached file QueueExampleLong3).
many more 'rounds' can be run with this logic and the above configuration. after about 4060 rounds the OOM in the java heap space occurs again. when running with 500K messages the OOM occurs after 817 rounds (factor 5 matches for sizes and number of rounds). these tests were done with a DLQ specified. i assume that a similar or alike behaviour can be expected with a DLQ as well.
attached you'll also find another screen shot und server log. the screen shot of the jconsole memory view shows the continous growth of memory over time.
thank you very much for your help. kind regards martin



> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: FullSize200.jpeg, FullSize200_Server.log, QueueExample.java, QueueExampleLong.java, QueueExampleLong2.java, QueueExampleLong3.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira