[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. now that all messages are received (and commited) the OOM condition no longer occurs. i'm sorry i did not figure out the issue in the test routine as well.
nevertheless the issue is still existent as the application guy does not issue a commit() until the message has been successfully processed (archived the document and updated some index tables). the application works in the same fashion as the main() method, it sleeps for a while, retries, rolls back, sleeps again. if the scanning process is heavily used hundreds of open messages queue up and are rolled back again and again. if the outage of the archive system or database server takes some time, the OOM occurs sooner or later.
what is expected is that if MaxDeliveryAttempts is reached, the message is discarded (or put to a DLQ, if defined) and the associated memory should be cleaned up. there should be no need to issue a commit(), the memory in my opinion should be freed at the latest when the connection is closed. as it is also done in our example (before going to sleep again).
thanks very much for your efforts putting into this.
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: QueueExample.java, QueueExampleLong.java, QueueExampleLong2.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