[
https://issues.apache.org/activemq/browse/AMQ-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yannick updated AMQ-2159:
-------------------------
Description:
A problem in message eviction seems to cause a strange behavior of message
delivery. After a slow consumer consumed it's prefetched messages, it start
receiving one message out of two that were produced. When stepping into the
sources I noticed that one message evicted out of two is dispatched to the
destination even if no message have been consumed during that time. The problem
seems to be in the class 'TopicSubscription'. This is what I found:
- When a message is discarded dequeueCounter is incremented.
- Then next time a message arrives it is evicted then dispatchMatched is
called.
- Because dequeueCounter have been called without any message dispatched,
isFull() return false.
- As a result it assumes there is an empty room in the prefetch and dispatch
the message.
The following example show what I expect against what I get when I produce 100
messages with a unique ID then consume 10 message and output the message ID.
Prefetch size is 5. and constantPendingMessageLimitStrategy limit="5"
Expected:
0, 1, 2, 3, 4, 95, 96, 97, 98, 99
What I really get
0, 1, 2, 3, 4, 5, 7, 9, 11, 13
I made a test application and a unit test, I didn't found how to attach it to
the issue.
was:
A problem in message eviction seems to cause a strange behavior of message
delivery. After a slow consumer consumed it's prefetched messages, it start
receiving one message out of two that were produced. When stepping into the
sources I noticed that one message evicted out of two is dispatched to the
destination even if no message have been consumed during that time. The problem
seems to be in the class 'TopicSubscription'. This is what I found:
- When a message is discarded dequeueCounter is incremented.
- Then next time a message arrives it is evicted then dispatchMatched is
called.
- Because dequeueCounter have been called without any message dispatched,
isFull() return false.
- As a result it assumes there is an empty room in the prefetch and dispatch
the message.
The following example show what I expect against what I get when I produce 100
messages with a unique ID then consume 10 message and output the message ID.
Prefetch size is 5.
Expected:
0, 1, 2, 3, 4, 95, 96, 97, 98, 99
What I really get
0, 1, 2, 3, 4, 5, 7, 9, 11, 13
I made a test application and a unit test, I didn't found how to attach it to
the issue.
> One evicted message out of two is delivered to the consumer
> -----------------------------------------------------------
>
> Key: AMQ-2159
> URL: https://issues.apache.org/activemq/browse/AMQ-2159
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.2.0
> Environment: Windows Xp, Java 5, ActiveMQ 5.2
> Reporter: Yannick
> Attachments: testActiveMQ.zip
>
>
> A problem in message eviction seems to cause a strange behavior of message
> delivery. After a slow consumer consumed it's prefetched messages, it start
> receiving one message out of two that were produced. When stepping into the
> sources I noticed that one message evicted out of two is dispatched to the
> destination even if no message have been consumed during that time. The
> problem seems to be in the class 'TopicSubscription'. This is what I found:
> - When a message is discarded dequeueCounter is incremented.
> - Then next time a message arrives it is evicted then dispatchMatched is
> called.
> - Because dequeueCounter have been called without any message dispatched,
> isFull() return false.
> - As a result it assumes there is an empty room in the prefetch and dispatch
> the message.
> The following example show what I expect against what I get when I produce
> 100 messages with a unique ID then consume 10 message and output the message
> ID. Prefetch size is 5. and constantPendingMessageLimitStrategy limit="5"
> Expected:
> 0, 1, 2, 3, 4, 95, 96, 97, 98, 99
> What I really get
> 0, 1, 2, 3, 4, 5, 7, 9, 11, 13
> I made a test application and a unit test, I didn't found how to attach it to
> the issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
