[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Howard Gao commented on JBMESSAGING-1685:
-----------------------------------------
Hi Martin,
If I didn't understand wrong, the problem is that there is too much messages in the
DLQ and this caused OOM. The DLQ is just like any other queues in JBM, which will holds
messages that are sent to it. To control the memory usage of a queue, you can limit the
number of messages that reside in memory by specifying fullSize/pageSize/downCacheSize
attributes of the queue. Any more messages that exceed the fullSize will be stored to DB
and later will be loaded as the messages are being delivered off.
The properties are described in the JBM doc. Please try it and see if the OOM is gone.
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