activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Lisachenko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-5179) queuesize can be unreliable
Date Thu, 18 Dec 2014 08:26:14 GMT

    [ https://issues.apache.org/jira/browse/AMQ-5179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14251369#comment-14251369
] 

Alexander Lisachenko commented on AMQ-5179:
-------------------------------------------

This issue is still present. However, there is no reliable way to reproduce it, looks like
it's a result of race conditions.

Our case is following: STOMP producers that send messages to the virtual topics and STOMP
consumers on physical queues, mapped to the virtual topics. Messages can be persistent or
not. After week or several days of uptime, queue counter in the web console, /admin/xml/queues.jsp
and jooloka can return invalid queue size, however when trying to browse it or consume messages
- no pending messages in the queue.

> queuesize can be unreliable 
> ----------------------------
>
>                 Key: AMQ-5179
>                 URL: https://issues.apache.org/jira/browse/AMQ-5179
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.9.0, 5.9.1
>         Environment: windows 8.1, centOS 6.4
>            Reporter: Morteza
>              Labels: monitoring, queue
>         Attachments: 1.png, 2.png, AMQ5179Test.java, Manipulator2.java, activemq.xml
>
>
> We noticed that sometimes queuesize attribute of some queues are different from the count
of messages that exist in the queue. for example queuesize is 9 but there are no messages
in the queue. This issue has happened frequently so after investigation we created a test
case for the problem.
> The test case creates 5 message that each consist of an array of 1 million random bytes.
On first run it creates the 5 messages and queuesize becomes 5 as expected. On subsequent
runs the messages won't persist on queue but queue size is increased by 5.
> Now as a client the code could be improved to prevent such problem but from the perspective
of someone who wants to monitor broker states, this is a total failure since she can't know
the amount of remaining messages on a queue. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message