You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Dominic Tootell (JIRA)" <ji...@apache.org> on 2010/12/03 17:31:10 UTC

[jira] Updated: (AMQ-3061) Broker Deadlock when limiting size of temp store, and using VirtualTopics

     [ https://issues.apache.org/jira/browse/AMQ-3061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dominic Tootell updated AMQ-3061:
---------------------------------

    Attachment: StoreQueueCursor.java
                FilePendingMessageCursor.java
                Queue.java

Adding 3 potential patches. 

- Have run against the unit test provided.
- Have run against the 5.4.1 src (*{{mvn test}}*)


However, I'm not 100% sure these patches are good, reason being is that in Queue.java I've stopped the *{{checkUsage()}}* in doMessageSend(..).  Which is encroaching on ProducerFlowControl, so concerns me a little.  Anyways, I'll attach for you to look at.

/dom

> Broker Deadlock when limiting size of temp store, and using VirtualTopics
> -------------------------------------------------------------------------
>
>                 Key: AMQ-3061
>                 URL: https://issues.apache.org/jira/browse/AMQ-3061
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.3.2, 5.4.1
>         Environment: Mac 10.6.5 (and Linux Centos)
>            Reporter: Dominic Tootell
>         Attachments: activemq-deadlock-replication-541.tar.gz, FilePendingMessageCursor.java, FilePendingMessageCursor.patch.txt, Queue.java, Queue.patch.txt, StoreQueueCursor.java, StoreQueueCursor.patch.txt
>
>
> When limiting the Temp Table space the broker will dead lock:
> - 1 Producer Thread (own connection) writing to VirtualTopic.FooTwo
> -- writes 40000 messages
> - 2 Consumer Threads (each own connection) consuming from Consumer.X.VirtualTopic.FooTwo
> -- consumes message (auto ack - but message ack for good measure - delay of 100ms between consumption)
> The dead lock occurs when using the either the KahaDB or ActiveMQPersistence persistence, and seems more related to the KahaDB implementation used for the Temp storage area.
> I shall attach a test jar, which is a executable jar, from which the issue can be replicated (I shall attach a zip of the source too - maven project)
> The tests can be run as:
> - java -classpath 5.4.1-deadlock-jar-with-dependencies.jar bbc.forge.domt.activemq.investigation.KahaDBTempStorageDeadlockReplication54Test
> or 
> - java -classpath 5.4.1-deadlock-jar-with-dependencies.jar bbc.forge.domt.activemq.investigation.TempStorageDeadlockReplication54Test
> These classes are also Unit Test Cases.  
> - Producer logs to producer.log
> - Consumes log to consumer.log
> - A Monitor thread just run in the background that detail the number of messages sent and consumed... logs to monitor.log
> - tests write to the dir *{{target/activemq-data}}*
> To disable limiting the temp storage add the System property *{{limit.temp=false}}*, i.e.
> - java -Dlimit.temp=false -classpath 5.4.1-deadlock-jar-with-dependencies.jar bbc.forge.domt.activemq.investigation.TempStorageDeadlockReplication54Test
> This seems to be a different/additional issue to AMQ-2475
> thanks in advance, let me know if you need any more information.
> /dom

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.