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

[Howard Gao (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477873#action_12477873 ] 

Howard Gao commented on JBMESSAGING-1685:
-----------------------------------------

Hi Martin,

Thanks for the info. I examined my first test and found it's not a valid one. The reason is that for every loop it sends 200 messages and only received one. So the 199 messages are left in the queue. As you added the loops the message are accumulated and eventually use up the memory.

I attached a new test that comsumes all the messages after roll back so no messages are left in each loop. And it passes 1000 loops safely.

To run the test, you need to add "MaxDeliveryAttempts" to 2000 in the queue configuration file so message won't be put to the DLQ after 10 times of roll backs.

Can you take a look (it's QueueExampleLong2.java)? Thanks.

Howard



> 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, 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