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

["Dominic Tootell (Commented) (JIRA)" <ji...@apache.org>]

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

Dominic Tootell commented on AMQ-3061:
--------------------------------------

Hi,

I've recently come back to this and noticed that the patch contained a bug in the Queue.java 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:
{noformat}
		if (message.isPersistent()) {
			checkUsage(context, message);
		} else if (messages.getSystemUsage() != null) {
			systemUsage.getTempUsage().isFull();
		}
{noformat}

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
/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: FilePendingMessageCursor.java, FilePendingMessageCursor.patch.txt, Queue.java, Queue.patch.txt, StoreQueueCursor.java, 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 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira