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

Justin Bertram commented on AMQ-9512:
-------------------------------------

For what it's worth, all of the actual implementations of 
{{org.apache.activemq.store.TopicMessageStore#recoverNextMessages}} are either 
using {{synchronized}} or some other kind of lock. This includes:
* {{org.apache.activemq.store.jdbc.JDBCTopicMessageStore#recoverNextMessages}} 
(your case)
* 
{{org.apache.activemq.store.kahadb.KahaDBStore.KahaDBTopicMessageStore#recoverNextMessages}}
 (using a {{ReentrantReadWriteLock.WriteLock}})
* 
{{org.apache.activemq.store.kahadb.TempKahaDBStore.KahaDBTopicMessageStore#recoverNextMessages}}
 (using {{synchronized}})
* 
{{org.apache.activemq.store.memory.MemoryTopicMessageStore#recoverNextMessages}}
 (using {{synchronized}})

The thread dumps themselves don't contain any deadlocks. They simply contain a 
number of threads in a {{BLOCKED}} state due to the synchronization. In each 
thread dump a different thread is holding the lock which indicates that nothing 
is stuck, per se. The broker is making progress, albeit slowly. It may simply 
be that the database or the network is slow or just that this is the "cost of 
doing business" with JDBC. Generally speaking, JDBC is the slowest option for 
message storage. You may have better luck using shared storage with KahaDB.

> Latencies with large synchrized blocks in JDBC persistence adapter
> ------------------------------------------------------------------
>
>                 Key: AMQ-9512
>                 URL: https://issues.apache.org/jira/browse/AMQ-9512
>             Project: ActiveMQ Classic
>          Issue Type: Bug
>            Reporter: Jean-Louis Monteiro
>            Priority: Major
>         Attachments: stack-1, stack-2, stack-3, stack-4, stack-5
>
>
> When running ActiveMQ with a JDBC Persistence Adapter, I'm facing slow or 
> irresponsive situations with ActiveMQ.
> I spotted (maybe badly) this one: 
> [https://github.com/apache/activemq/blob/2f40261362bb830899f7f369a731b446f795a627/activemq-jdbc-store/src/main/java/org/apache/activemq/store/jdbc/JDBCTopicMessageStore.java#L262]
> Here are a couple of thread dumps at different moments that can demonstrate 
> the situation hopefully.
> Not sure if this is the root cause or not, but anyways, the class seems 
> inconsistent. The method is synchronized even though it seems to be a read 
> only operation only. The rest of the class isn't thread safe at all, so I'm 
> wondering what's the purpose.
> Second option would be to go fine grain with a ReentrantReadWriteLock maybe
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org
For additional commands, e-mail: issues-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact


Reply via email to