[
https://issues.apache.org/jira/browse/AMQ-5529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Smith updated AMQ-5529:
----------------------------
Attachment: amq_jstack.txt
> Deadlock using JMX & copyMatchingMessagesTo
> -------------------------------------------
>
> Key: AMQ-5529
> URL: https://issues.apache.org/jira/browse/AMQ-5529
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMX
> Affects Versions: 5.10.0
> Environment: Linux app1.syd.acx 2.6.39-200.24.1.el6uek.x86_64 #1 SMP
> Sat Jun 23 02:39:07 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_60"
> Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
> Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode)
> Reporter: Paul Smith
> Attachments: amq_jstack.txt
>
>
> Today we had an issue relating to a consumer that was somehow not properly
> ack'ing messages and letting the queue grow.
> We had the idea to use JMX operations to move messages we knew had been
> delivered and processed, but before hand tried to copy a few of the messages
> to a new destination to confirm using a selector of
> "JMSTimestamp<[timestampAsLongValueOfYesterdayMorning]" (obviously a
> long-based timestamp I've since forgotten to write down.
> I tested the Selector with a browse(String selector) operation, and that
> successfully returned the small handful easily.
> I invoked the copyMatchingMessagesTo Operation on the Queue JMX operation,
> and the attached Thread Deadlock occurred. At the time there were around
> 20,000 messages in the queue, all very small in size.(roughly 1k each as
> reported by the JMX averageMessageSize property)
> This doesn't give us much confidence in the ability to use Operational JMX to
> recover from strange scenarios. The total number of messages being copied
> was a small handful, 5-20 at most.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
