You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org> on 2007/06/26 16:49:26 UTC
[jira] Created: (QPID-531) [Memory Leak] Broker retains messages
that are consumed with NO_ACK
[Memory Leak] Broker retains messages that are consumed with NO_ACK
-------------------------------------------------------------------
Key: QPID-531
URL: https://issues.apache.org/jira/browse/QPID-531
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: M2
Reporter: Martin Ritchie
Assignee: Rupert Smith
Fix For: M2
When testing consuming messages via NO_ACK the broker continually OOMEd. Switching to AUTO_ACK cleared things up.
Looks like that the broker, while dequeing NO_ACK msgs is not allowing them to be gc'd. May be due to the way the Queue and the PDQ interact. Messages were being sent to a Topic and consumed by a two clients.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (QPID-531) [Memory Leak] Broker retains messages
that are consumed with NO_ACK
Posted by "Rupert Smith (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rupert Smith resolved QPID-531.
-------------------------------
Resolution: Fixed
Cannot reproduce. NO_ACK perf tests are running constantly for hours without OOME.
> [Memory Leak] Broker retains messages that are consumed with NO_ACK
> -------------------------------------------------------------------
>
> Key: QPID-531
> URL: https://issues.apache.org/jira/browse/QPID-531
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Rupert Smith
> Fix For: M2
>
>
> When testing consuming messages via NO_ACK the broker continually OOMEd. Switching to AUTO_ACK cleared things up.
> Looks like that the broker, while dequeing NO_ACK msgs is not allowing them to be gc'd. May be due to the way the Queue and the PDQ interact. Messages were being sent to a Topic and consumed by a two clients.
> Running two sustained.TestClient
> - Producer
> - Consumer
> and a sustained.TestCoordinator with -DackMode=257 (for no_ack) should cause the broker to fail fairly quickly.
> More docs on this test can be found on the wiki: http://cwiki.apache.org/qpid/sustained-tests.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-531) [Memory Leak] Broker retains messages
that are consumed with NO_ACK
Posted by "Rupert Smith (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528765 ]
Rupert Smith commented on QPID-531:
-----------------------------------
Martin, have you figured out a way to reproduce the problem? Did I just not run the NO_ACK test for long enough to show this one up?
> [Memory Leak] Broker retains messages that are consumed with NO_ACK
> -------------------------------------------------------------------
>
> Key: QPID-531
> URL: https://issues.apache.org/jira/browse/QPID-531
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M2
>
>
> When testing consuming messages via NO_ACK the broker continually OOMEd. Switching to AUTO_ACK cleared things up.
> Looks like that the broker, while dequeing NO_ACK msgs is not allowing them to be gc'd. May be due to the way the Queue and the PDQ interact. Messages were being sent to a Topic and consumed by a two clients.
> Running two sustained.TestClient
> - Producer
> - Consumer
> and a sustained.TestCoordinator with -DackMode=257 (for no_ack) should cause the broker to fail fairly quickly.
> More docs on this test can be found on the wiki: http://cwiki.apache.org/qpid/sustained-tests.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (QPID-531) [Memory Leak] Broker retains messages
that are consumed with NO_ACK
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie resolved QPID-531.
---------------------------------
Resolution: Fixed
The broker was recording the msgs for ack.
> [Memory Leak] Broker retains messages that are consumed with NO_ACK
> -------------------------------------------------------------------
>
> Key: QPID-531
> URL: https://issues.apache.org/jira/browse/QPID-531
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M2.1
>
>
> When testing consuming messages via NO_ACK the broker continually OOMEd. Switching to AUTO_ACK cleared things up.
> Looks like that the broker, while dequeing NO_ACK msgs is not allowing them to be gc'd. May be due to the way the Queue and the PDQ interact. Messages were being sent to a Topic and consumed by a two clients.
> Running two sustained.TestClient
> - Producer
> - Consumer
> and a sustained.TestCoordinator with -DackMode=257 (for no_ack) should cause the broker to fail fairly quickly.
> More docs on this test can be found on the wiki: http://cwiki.apache.org/qpid/sustained-tests.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (QPID-531) [Memory Leak] Broker retains messages
that are consumed with NO_ACK
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie reopened QPID-531:
---------------------------------
Messages that are NO_ACK'd are not correctly removed from the messages store with a decrementReference.
> [Memory Leak] Broker retains messages that are consumed with NO_ACK
> -------------------------------------------------------------------
>
> Key: QPID-531
> URL: https://issues.apache.org/jira/browse/QPID-531
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Rupert Smith
> Fix For: M2
>
>
> When testing consuming messages via NO_ACK the broker continually OOMEd. Switching to AUTO_ACK cleared things up.
> Looks like that the broker, while dequeing NO_ACK msgs is not allowing them to be gc'd. May be due to the way the Queue and the PDQ interact. Messages were being sent to a Topic and consumed by a two clients.
> Running two sustained.TestClient
> - Producer
> - Consumer
> and a sustained.TestCoordinator with -DackMode=257 (for no_ack) should cause the broker to fail fairly quickly.
> More docs on this test can be found on the wiki: http://cwiki.apache.org/qpid/sustained-tests.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-531) [Memory Leak] Broker retains messages
that are consumed with NO_ACK
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie updated QPID-531:
--------------------------------
Fix Version/s: (was: M2)
M2.1
> [Memory Leak] Broker retains messages that are consumed with NO_ACK
> -------------------------------------------------------------------
>
> Key: QPID-531
> URL: https://issues.apache.org/jira/browse/QPID-531
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M2.1
>
>
> When testing consuming messages via NO_ACK the broker continually OOMEd. Switching to AUTO_ACK cleared things up.
> Looks like that the broker, while dequeing NO_ACK msgs is not allowing them to be gc'd. May be due to the way the Queue and the PDQ interact. Messages were being sent to a Topic and consumed by a two clients.
> Running two sustained.TestClient
> - Producer
> - Consumer
> and a sustained.TestCoordinator with -DackMode=257 (for no_ack) should cause the broker to fail fairly quickly.
> More docs on this test can be found on the wiki: http://cwiki.apache.org/qpid/sustained-tests.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (QPID-531) [Memory Leak] Broker retains messages
that are consumed with NO_ACK
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie reassigned QPID-531:
-----------------------------------
Assignee: Martin Ritchie (was: Rupert Smith)
> [Memory Leak] Broker retains messages that are consumed with NO_ACK
> -------------------------------------------------------------------
>
> Key: QPID-531
> URL: https://issues.apache.org/jira/browse/QPID-531
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M2
>
>
> When testing consuming messages via NO_ACK the broker continually OOMEd. Switching to AUTO_ACK cleared things up.
> Looks like that the broker, while dequeing NO_ACK msgs is not allowing them to be gc'd. May be due to the way the Queue and the PDQ interact. Messages were being sent to a Topic and consumed by a two clients.
> Running two sustained.TestClient
> - Producer
> - Consumer
> and a sustained.TestCoordinator with -DackMode=257 (for no_ack) should cause the broker to fail fairly quickly.
> More docs on this test can be found on the wiki: http://cwiki.apache.org/qpid/sustained-tests.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-531) [Memory Leak] Broker retains messages
that are consumed with NO_ACK
Posted by "Rupert Smith (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509574 ]
Rupert Smith commented on QPID-531:
-----------------------------------
I'm trying to reproduce this independantly with the performance tests. I set up a pub/sub 1:10 ping test with no ack mode:
./Ping-Once-Async.sh -c[8] -s[1000] -d1D ackMode=257 pubsub=true destinationCount=10 messageSize=256 transacted=false
And letting it run. No out of memory error encountered in the first 5 minutes. Still running...
> [Memory Leak] Broker retains messages that are consumed with NO_ACK
> -------------------------------------------------------------------
>
> Key: QPID-531
> URL: https://issues.apache.org/jira/browse/QPID-531
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Rupert Smith
> Fix For: M2
>
>
> When testing consuming messages via NO_ACK the broker continually OOMEd. Switching to AUTO_ACK cleared things up.
> Looks like that the broker, while dequeing NO_ACK msgs is not allowing them to be gc'd. May be due to the way the Queue and the PDQ interact. Messages were being sent to a Topic and consumed by a two clients.
> Running two sustained.TestClient
> - Producer
> - Consumer
> and a sustained.TestCoordinator with -DackMode=257 (for no_ack) should cause the broker to fail fairly quickly.
> More docs on this test can be found on the wiki: http://cwiki.apache.org/qpid/sustained-tests.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-531) [Memory Leak] Broker retains messages
that are consumed with NO_ACK
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie updated QPID-531:
--------------------------------
Description:
When testing consuming messages via NO_ACK the broker continually OOMEd. Switching to AUTO_ACK cleared things up.
Looks like that the broker, while dequeing NO_ACK msgs is not allowing them to be gc'd. May be due to the way the Queue and the PDQ interact. Messages were being sent to a Topic and consumed by a two clients.
Running two sustained.TestClient
- Producer
- Consumer
and a sustained.TestCoordinator with -DackMode=257 (for no_ack) should cause the broker to fail fairly quickly.
More docs on this test can be found on the wiki: http://cwiki.apache.org/qpid/sustained-tests.html
was:
When testing consuming messages via NO_ACK the broker continually OOMEd. Switching to AUTO_ACK cleared things up.
Looks like that the broker, while dequeing NO_ACK msgs is not allowing them to be gc'd. May be due to the way the Queue and the PDQ interact. Messages were being sent to a Topic and consumed by a two clients.
> [Memory Leak] Broker retains messages that are consumed with NO_ACK
> -------------------------------------------------------------------
>
> Key: QPID-531
> URL: https://issues.apache.org/jira/browse/QPID-531
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: M2
> Reporter: Martin Ritchie
> Assignee: Rupert Smith
> Fix For: M2
>
>
> When testing consuming messages via NO_ACK the broker continually OOMEd. Switching to AUTO_ACK cleared things up.
> Looks like that the broker, while dequeing NO_ACK msgs is not allowing them to be gc'd. May be due to the way the Queue and the PDQ interact. Messages were being sent to a Topic and consumed by a two clients.
> Running two sustained.TestClient
> - Producer
> - Consumer
> and a sustained.TestCoordinator with -DackMode=257 (for no_ack) should cause the broker to fail fairly quickly.
> More docs on this test can be found on the wiki: http://cwiki.apache.org/qpid/sustained-tests.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.