[jira] [Updated] (AMQ-7039) consummer.receive(timeout) doesn't wait for timeout when the broker has a 0 QueuePrefetch PolicyEntry and is killed

["Jon Harper (JIRA)" <ji...@apache.org>]

     [ 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)