[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:
--------------------------------------

    Description: 
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.

  was:
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 so many rollback() operation, 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.
we do not use XA.

thanks for your help.



> 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: Tim Fox
>             Fix For: 1.4.3.GA
>
>
> 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