[
https://issues.apache.org/jira/browse/AMQ-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated AMQ-7039:
--------------------------------------
Component/s: JMS client
> 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
> Components: JMS client
> Affects Versions: 5.13.3
> Reporter: Jon Harper
> Assignee: Jean-Baptiste Onofré
> 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)
