[
https://issues.apache.org/jira/browse/ARTEMIS-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-1459:
------------------------------------
Description:
In some use cases a warning like the following is seen in broker's log:
{noformat}
[Thread-17
(ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@5c18298f)]
09:17:16,748 WARN [org.apache.activemq.artemis.core.server] AMQ222197:
Internal error! Delivery logic has identified a non delivery and still handled
a consumer!{noformat}
I've managed to recreate a situation that can reproduce this, even though the
test is an artificial one. Here is the sequence of events that can make this
warning show up:
# Start a broker with a queue
# Create 3 consumers - consumer 1, 2, and 3
# Send a message to the queue
# {{QueueImpl.deliver()}} starts working
# The message in queue first goes to consumer1, but consumer1 is BUSY
# The queue then tries consumer2, but before doing that consumer3 is closed.
# consumer2 happens is BUSY too
# Then the queue will try consumer1 again. This time consumer1 handled the
message. After that the values of the variables are like this:
{noformat}
pos == endPos == 0;
noDelivery == size == 2
handledConsumer != null{noformat}
Thus produces the above warning log.
I can't prove that this is the one and only case of such situation. It only
shows the possibility.
I'm not sure how to 'fix' that. At least for this case it does no real harm.
I'd prefer to 'downgrade' the warning into debug level.
was:
In some use cases a warning like the following is seen in broker's log:
[Thread-17
(ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@5c18298f)]
09:17:16,748 WARN [org.apache.activemq.artemis.core.server] AMQ222197:
Internal error! Delivery logic has identified a non delivery and still handled
a consumer!
I've managed to recreate a situation that can reproduce this, even though the
test is an artificial one. Here is the sequence of events that can make this
warning show up:
1. Start a broker, setting up a queue.
2. Create 3 consumers, consumer1, 2 and 3.
3. Send a message, QueueImpl.deliver() starts working
4. The message in queue first goes to consumer1 and consumer1
happens to be BUSY.
5. The queue then tries consumer2, but before doing that,
consumer3 is closed.
6. consumer2 happens to be BUSY too.
7. Then the queue will try consumer1 again. This time
consumer handled the message. After that the values of
the variables are like that:
pos == endPos == 0;
noDelivery == size == 2
handledConsumer != null
Thus produces the above warning log.
I can't prove that this is the one and only case of such situation.
It only shows the possibility.
I'm not sure how to 'fix' that. At least for this case it does no
real harm. I'd prefer to 'downgrade' the warning into debug level.
> QueueImpl.deliver() warning message
> -----------------------------------
>
> Key: ARTEMIS-1459
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1459
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 1.5.5, 2.3.0
> Reporter: Howard Gao
> Assignee: Howard Gao
> Priority: Minor
>
> In some use cases a warning like the following is seen in broker's log:
> {noformat}
> [Thread-17
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@5c18298f)]
> 09:17:16,748 WARN [org.apache.activemq.artemis.core.server] AMQ222197:
> Internal error! Delivery logic has identified a non delivery and still
> handled a consumer!{noformat}
> I've managed to recreate a situation that can reproduce this, even though the
> test is an artificial one. Here is the sequence of events that can make this
> warning show up:
> # Start a broker with a queue
> # Create 3 consumers - consumer 1, 2, and 3
> # Send a message to the queue
> # {{QueueImpl.deliver()}} starts working
> # The message in queue first goes to consumer1, but consumer1 is BUSY
> # The queue then tries consumer2, but before doing that consumer3 is closed.
> # consumer2 happens is BUSY too
> # Then the queue will try consumer1 again. This time consumer1 handled the
> message. After that the values of the variables are like this:
> {noformat}
> pos == endPos == 0;
> noDelivery == size == 2
> handledConsumer != null{noformat}
> Thus produces the above warning log.
> I can't prove that this is the one and only case of such situation. It only
> shows the possibility.
> I'm not sure how to 'fix' that. At least for this case it does no real harm.
> I'd prefer to 'downgrade' the warning into debug level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
