[
https://issues.apache.org/jira/browse/AMQ-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Harper updated AMQ-7039:
----------------------------
Description:
Start a broker with
{code:xml}
<policyEntry queue=">" queuePrefetch="0"/>
{code}
Run a client with the failover transport that has code like:
{code:java}
while (true) {
consummer.receive(1000);
}
{code}
When you kill the server, the client goes into a busy loop and uses 100% cpu.
This does not happen when the policyentry has the default queuePrefetch.
This seems to be because the ActiveMQMessageConsummer receives the command to
update its prefetchSize value but only updates CurrentPrefetchSize and not
prefetchSize.
In sendPullCommand, getCurrentPrefetchSize is checked to send or not a
pullcomand, but then just after in receive(timout) prefetchSize is checked to
call dequeue(-1) or dequeue(timeout)
Attached is a maven testcase that reproduces the problem:
{noformat}
$ mvn clean test
testQueuePrefetch1000 OK
testQueuePrefetch0 KO
Results :
Failed tests: testQueuePrefetch0(QueuePrefetchBusyLoopTestCase): receive
should block even when the broker is shutdown
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0
{noformat}
was:
Start a broker with
{{noformat}}
<policyEntry queue=">" queuePrefetch="0"/>
{{noformat}}
Run a client with the failover transport that has code like:
{{noformat}}
while (true) {
consummer.receive(1000);
}
{{noformat}}
When you kill the server, the client goes into a busy loop and uses 100% cpu.
This does not happen when the policyentry has the default queuePrefetch.
This seems to be because the ActiveMQMessageConsummer receives the command to
update its prefetchSize value but only updates CurrentPrefetchSize and not
prefetchSize.
In sendPullCommand, getCurrentPrefetchSize is checked to send or not a
pullcomand, but then just after in receive(timout) prefetchSize is checked to
call dequeue(-1) or dequeue(timeout)
Attached is a maven testcase that reproduces the problem:
{{noformat}}
$ mvn clean test
testQueuePrefetch1000 OK
testQueuePrefetch0 KO
Results :
Failed tests: testQueuePrefetch0(QueuePrefetchBusyLoopTestCase): receive
should block even when the broker is shutdown
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0
{{noformat}}
> consummer.receive(timeout) doesn't wait for timeout when the broker has a 0
> QueuePrefetch PolicyEntry and is killed
> -------------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-7039
> URL: https://issues.apache.org/jira/browse/AMQ-7039
> Project: ActiveMQ
> Issue Type: Bug
> Reporter: Jon Harper
> Priority: Major
> Attachments: QueuePrefetchBusyLoopTestCase.zip
>
>
> Start a broker with
> {code:xml}
> <policyEntry queue=">" queuePrefetch="0"/>
> {code}
> Run a client with the failover transport that has code like:
> {code:java}
> while (true) {
> consummer.receive(1000);
> }
> {code}
> When you kill the server, the client goes into a busy loop and uses 100% cpu.
> This does not happen when the policyentry has the default queuePrefetch.
> This seems to be because the ActiveMQMessageConsummer receives the command to
> update its prefetchSize value but only updates CurrentPrefetchSize and not
> prefetchSize.
> In sendPullCommand, getCurrentPrefetchSize is checked to send or not a
> pullcomand, but then just after in receive(timout) prefetchSize is checked to
> call dequeue(-1) or dequeue(timeout)
> Attached is a maven testcase that reproduces the problem:
> {noformat}
> $ mvn clean test
> testQueuePrefetch1000 OK
> testQueuePrefetch0 KO
> Results :
> Failed tests: testQueuePrefetch0(QueuePrefetchBusyLoopTestCase): receive
> should block even when the broker is shutdown
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
