You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Howard Gao (JIRA)" <ji...@apache.org> on 2017/10/11 01:42:00 UTC
[jira] [Updated] (ARTEMIS-1459) QueueImpl.deliver() warning message
[ https://issues.apache.org/jira/browse/ARTEMIS-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard Gao updated ARTEMIS-1459:
--------------------------------
Description:
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.
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;
noDel == 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
> Fix For: 1.5.6, 2.4.0
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)