[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 ran your example and it's working fine. since our application guys use JMS for handling large PDFs (generated by a scanner application, to be stored in an archive system) i took your example and
made the message size larger. in addition i put a loop around the execution instruction in the main() method => new QueueExampleLong().run(); to get this running in a loop one must also remove the System.exit() instruction in method
reportResultAndExit of class ExampleSupport.

running this code produces the OOM condition after approximately 194 rounds when running with a message size of 10000 bytes. when running with a size of 100000 bytes the OOM condition occurs after 20 rounds. these values multipled by factor
200 (number of sent messages) both calc up to approximately 390-400 MB. it looks like if the messages are being kept in memory, although doing a final commit() on the session and closing the connection.

attached you'll find the modified code QueueExampleLong.java and two images showing the java heap memory chart out of jconsole and the jboss console showing the OOM condition.
if i can help you any further with more testing or whatever, please let me know. thank you very much for your efforts putting into this.
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
>
>
> 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