[
https://issues.apache.org/jira/browse/QPID-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8393:
-----------------------------
Description:
When message is deleted concurrently (for example, with ring overflow policy,
invocation Queue#clear, TTL expiration, etc ), a {{StackOverflowError}} can be
thrown on attempt to add {{StateChangeListener}} to the entry.
For example, a queue entry can be deleted concurrently with
{{RingOverflowPolicyHandler#checkOverflow()}} and {{Queue#clear}}. In both
cases {{QueueEntry#acquireOrSteal(Runnable)}} is called. Only one of the
operation can acquire the entry, whilst the other should set
{{StateChangeListener}}. In unlucky circumstances, the setting of
{{StateChangeListener}} can fail with {{StackOverflowError}}:
{noformat}
########################################################################
#
# Unhandled Exception java.lang.StackOverflowError in Thread qtp587966210-134
#
# Exiting
#
########################################################################
java.lang.StackOverflowError
at
org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
at
org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
at
org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
at
org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
...
{noformat}
I used the following steps to reproduce the issue:
* created a queue with "ring overflow policy" and max message depth of 100
* flooded the queue with tons of asynchronously published messages from
concurrent producers (I used 30 producers sending 2000 messages each)
* when overflow policy starts deleting the queue entries, I cleared the queue
from web management console
* watched broker crush due to {{StackOverflowError}} thrown for the management
operation
Attached a sample class to reproduce the issue with legacy JMS client
was:
When message is deleted concurrently (for example, with ring overflow policy,
invocation Queue#clear, TTL expiration, etc ), a {{StackOverflowError}} can be
thrown on attempt to add {{StateChangeListener}} to the entry.
For example, a queue entry can be deleted concurrently with
{{RingOverflowPolicyHandler#checkOverflow()}} and {{Queue#clear}}. In both
cases {{QueueEntry#acquireOrSteal(Runnable)}} is called. Only one of the
operation can acquire the entry, whilst the other should set
{{StateChangeListener}}. In unlucky circumstances, the setting of
{{StateChangeListener}} can fail with {{StackOverflowError}}:
{noformat}
########################################################################
#
# Unhandled Exception java.lang.StackOverflowError in Thread qtp587966210-134
#
# Exiting
#
########################################################################
java.lang.StackOverflowError
at
org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
at
org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
at
org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
at
org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
...
{noformat}
I used the following steps to reproduce the issue:
* created a queue with "ring overflow policy" and max message depth of 100
* flooded the queue with tons of asynchronously published messages from
concurrent producers (I used 30)
* when overflow policy starts deleting the queue entries, I cleared the queue
from web management console
* watched broker crash due to {{StackOverflowError}} thrown for the management
operation
Attached a sample class to reproduce the issue with legacy JMS client
> [Broker-J] Broker can crash with StackOverflowError when deleting messages
> --------------------------------------------------------------------------
>
> Key: QPID-8393
> URL: https://issues.apache.org/jira/browse/QPID-8393
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2,
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1,
> qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2, qpid-java-6.0.7,
> qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4, qpid-java-broker-7.0.0,
> qpid-java-6.1.5, qpid-java-broker-7.0.1, qpid-java-6.1.7,
> qpid-java-broker-7.1.0, qpid-java-broker-7.0.4, qpid-java-broker-7.0.5,
> qpid-java-broker-7.0.6, qpid-java-broker-7.0.7, qpid-java-broker-7.1.1,
> qpid-java-broker-7.1.2, qpid-java-broker-7.0.8, qpid-java-broker-7.1.3,
> qpid-java-broker-7.1.4, qpid-java-broker-7.1.5, qpid-java-broker-7.1.6
> Reporter: Alex Rudyy
> Priority: Critical
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.0.9,
> qpid-java-broker-7.1.7
>
> Attachments: TestRunner.java
>
>
> When message is deleted concurrently (for example, with ring overflow policy,
> invocation Queue#clear, TTL expiration, etc ), a {{StackOverflowError}} can
> be thrown on attempt to add {{StateChangeListener}} to the entry.
> For example, a queue entry can be deleted concurrently with
> {{RingOverflowPolicyHandler#checkOverflow()}} and {{Queue#clear}}. In both
> cases {{QueueEntry#acquireOrSteal(Runnable)}} is called. Only one of the
> operation can acquire the entry, whilst the other should set
> {{StateChangeListener}}. In unlucky circumstances, the setting of
> {{StateChangeListener}} can fail with {{StackOverflowError}}:
> {noformat}
> ########################################################################
> #
> # Unhandled Exception java.lang.StackOverflowError in Thread qtp587966210-134
> #
> # Exiting
> #
> ########################################################################
> java.lang.StackOverflowError
> at
> org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
> at
> org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
> at
> org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
> at
> org.apache.qpid.server.util.StateChangeListenerEntry.add(StateChangeListenerEntry.java:57)
> ...
> {noformat}
> I used the following steps to reproduce the issue:
> * created a queue with "ring overflow policy" and max message depth of 100
> * flooded the queue with tons of asynchronously published messages from
> concurrent producers (I used 30 producers sending 2000 messages each)
> * when overflow policy starts deleting the queue entries, I cleared the
> queue from web management console
> * watched broker crush due to {{StackOverflowError}} thrown for the
> management operation
> Attached a sample class to reproduce the issue with legacy JMS client
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
