activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominic Tootell (Commented) (JIRA)" <>
Subject [jira] [Commented] (AMQ-3061) Broker Deadlock when limiting size of temp store, and using VirtualTopics
Date Sat, 08 Oct 2011 17:10:30 GMT


Dominic Tootell commented on AMQ-3061:


I've recently come back to this and noticed that the patch contained a bug in the
where the commented out *{{//checkUsage(context, message);}}* should have been replaced with
the follow; otherwise the percentageUsage on the persistence store wasn't calculated meaning
that *{{<storeUsage limit=}}* wasn't being applied:
		if (message.isPersistent()) {
			checkUsage(context, message);
		} else if (messages.getSystemUsage() != null) {

Also, the patch I provided was accidently coded against 5.4.1 of fuse's distribution.  So
sorry about that.


I've recently re-run the deadlock test against 5.5 release and the dead lock still occurs.
 What I think I'll do is open another a jira against 5.5 directly;
so that I can look soley at providing a patch for the 5.5 apache activemq version.

Big Apologies

> Broker Deadlock when limiting size of temp store, and using VirtualTopics
> -------------------------------------------------------------------------
>                 Key: AMQ-3061
>                 URL:
>             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:, FilePendingMessageCursor.patch.txt,, Queue.patch.txt,, StoreQueueCursor.patch.txt, activemq-deadlock-replication-541.tar.gz
> 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
> 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}}*,
> - 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.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message