Yuriy Sidelnikov created AMQ-4107:
-------------------------------------
Summary: Message order can be broken for Topic under a high load
when topicPrefetch=1 and comsumer is slow
Key: AMQ-4107
URL: https://issues.apache.org/jira/browse/AMQ-4107
Project: ActiveMQ
Issue Type: Bug
Components: Transport
Affects Versions: 5.6.0
Reporter: Yuriy Sidelnikov
For <amq:policyEntry topic=">" producerFlowControl="true" memoryLimit="30mb"
topicPrefetch="1" blockedProducerWarningInterval="30">
Short excerpt from TopicSubscription class:
public void add(MessageReference node) throws Exception {
…..
if (!isFull() && matched.isEmpty() && !isSlave()) {
// if maximumPendingMessages is set we will only discard messages
which
// have not been dispatched (i.e. we allow the prefetch buffer to
be filled)
dispatch(node); <- Second message will go this
way and might be dispatched sooner than first one.
setSlowConsumer(false);
} else {
…….
if (matched.tryAddMessageLast(node, 10)) { <- first message will be put in
the VMCursor queue and might be dispatched later
break;
}
.....
dispatchMatched(); <- First message won't be dispatched immediately because
!isFull() is still false
}
Possible scenario as I can see it from logs:
1. First message has arrived and !isFull() is false because consumer didn't
take some previous message yet.
2. First message will be processed by tryAddMessageLast in
VMPendingMessageCursor class and will be dispatched very lately because
!isFull() is still false.
3. Meanwhile consumer reads some previous message and !isFull() will return
true.
4. Second message will be dispatched immediately and might be first to be
delivered.
5. Then first message is dispatched.
6. Message order is broken.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira