[JBoss JIRA] Created: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
6:44 a.m.
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 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.
--
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
9:41 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
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
12:33 a.m.
New subject: [JBoss JIRA] Assigned: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Howard Gao reassigned JBMESSAGING-1685:
---------------------------------------
Assignee: Howard Gao (was: Tim Fox)
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.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
12:38 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Howard Gao updated JBMESSAGING-1685:
------------------------------------
Fix Version/s: 1.4.0.SP3.CP09
1.4.5.GA
(was: 1.4.3.GA)
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
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
1:32 a.m.
New subject: [JBoss JIRA] Commented: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Howard Gao commented on JBMESSAGING-1685:
-----------------------------------------
Hi Martin,
I created a simple test program where 2000 session.rollback() are performed. It runs
without any problem. I'll upload it and can you have a look please?
I tried with JBOSS 5.1.0.GA/jbm 1.4.3 as well as JBoss 4.2.3.GA / jbm 1.4.4.GA
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
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
1:34 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Howard Gao updated JBMESSAGING-1685:
------------------------------------
Attachment: QueueExample.java
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
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
4:25 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
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
4:25 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Martin Gysel updated JBMESSAGING-1685:
--------------------------------------
Attachment: QueueExampleLong.java
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
4:27 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Martin Gysel updated JBMESSAGING-1685:
--------------------------------------
Attachment: Test10K.jpg
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
4:27 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Martin Gysel updated JBMESSAGING-1685:
--------------------------------------
Attachment: Test100K.jpg
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
5:39 a.m.
New subject: [JBoss JIRA] Commented: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
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
5:45 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Howard Gao updated JBMESSAGING-1685:
------------------------------------
Attachment: QueueExampleLong2.java
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
8:29 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
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
1:10 a.m.
New subject: [JBoss JIRA] Commented: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
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
7:01 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Martin Gysel updated JBMESSAGING-1685:
--------------------------------------
Attachment: QueueExampleLong3.java
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,
QueueExampleLong3.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
7:05 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Martin Gysel updated JBMESSAGING-1685:
--------------------------------------
Attachment: FullSize200_Server.log
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: FullSize200.jpeg, FullSize200_Server.log, QueueExample.java,
QueueExampleLong.java, QueueExampleLong2.java, QueueExampleLong3.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
7:05 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Martin Gysel updated JBMESSAGING-1685:
--------------------------------------
Attachment: FullSize200.jpeg
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: FullSize200.jpeg, FullSize200_Server.log, QueueExample.java,
QueueExampleLong.java, QueueExampleLong2.java, QueueExampleLong3.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
7:25 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Martin Gysel updated JBMESSAGING-1685:
--------------------------------------
hi howard, thanks for your feedback. i changed the queue defs as follows:
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=testQueue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends
optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="MaxDeliveryAttempts">10</attribute>
<attribute name="FullSize">200</attribute>
<attribute name="PageSize">100</attribute>
<attribute name="DownCacheSize">100</attribute>
<attribute name="SecurityConfig">
<security>
<role name="guest" read="true"
write="true"/>
<role name="publisher" read="true"
write="true" create="false"/>
<role name="noacc" read="false" write="false"
create="false"/>
</security>
</attribute>
</mbean>
the test case with 100K messages should now occupy a max of about 20MB (200 x 100K).
before running the test again i changed the test program to adapt as realistic as possible
to our current application logic. so the loop now takes place in the main() method and in
the receiving of the messages (MaxDeliveryAttempts set to 10). there is no commit()
operation anymore ( see the attached file QueueExampleLong3).
many more 'rounds' can be run with this logic and the above configuration. after
about 4060 rounds the OOM in the java heap space occurs again. when running with 500K
messages the OOM occurs after 817 rounds (factor 5 matches for sizes and number of
rounds). these tests were done with a DLQ specified. i assume that a similar or alike
behaviour can be expected with a DLQ as well.
attached you'll also find another screen shot und server log. the screen shot of the
jconsole memory view shows the continous growth of memory over time.
thank you very much for your help. 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: FullSize200.jpeg, FullSize200_Server.log, QueueExample.java,
QueueExampleLong.java, QueueExampleLong2.java, QueueExampleLong3.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
2:22 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Howard Gao updated JBMESSAGING-1685:
------------------------------------
Fix Version/s: 1.4.0.SP3.CP10
1.4.6.GA
(was: 1.4.5.GA)
(was: 1.4.0.SP3.CP09)
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.CP10, 1.4.6.GA
Attachments: FullSize200.jpeg, FullSize200_Server.log, QueueExample.java,
QueueExampleLong.java, QueueExampleLong2.java, QueueExampleLong3.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
9:30 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Howard Gao updated JBMESSAGING-1685:
------------------------------------
Fix Version/s: 1.4.7.GA
(was: 1.4.6.GA)
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.CP10, 1.4.7.GA
Attachments: FullSize200.jpeg, FullSize200_Server.log, QueueExample.java,
QueueExampleLong.java, QueueExampleLong2.java, QueueExampleLong3.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
3:24 a.m.
New subject: [JBoss JIRA] Commented: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Howard Gao commented on JBMESSAGING-1685:
-----------------------------------------
A related bug has been found from this issue and fixed.
It should be noted that if a DLQ is used, it's fullSize should be set to a suitable
value to limit the memory used by DLQ.
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.CP10, 1.4.7.GA
Attachments: FullSize200.jpeg, FullSize200_Server.log, QueueExample.java,
QueueExampleLong.java, QueueExampleLong2.java, QueueExampleLong3.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
3:24 a.m.
New subject: [JBoss JIRA] Closed: (JBMESSAGING-1685) jboss messaging / memory leak on session.rollback() operation
[
https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.ji...
]
Howard Gao closed JBMESSAGING-1685.
-----------------------------------
Resolution: Done
done
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.CP10, 1.4.7.GA
Attachments: FullSize200.jpeg, FullSize200_Server.log, QueueExample.java,
QueueExampleLong.java, QueueExampleLong2.java, QueueExampleLong3.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
5300
days inactive
5469
days old
21 comments
2 participants
participants (2)
-
Howard Gao (JIRA) -
Martin Gysel (JIRA)