There's the per-durable-subscription lock called "pendingLock" inside the PrefetchSubscription and PrefetchSubscription#dispatchPending method grabs this mutex for message dispatching. In the ActiveMQ 5.7 that we use, there are 3 requests calling this #dispatchPending as follows:
PrefetchSubscription#dispatchPending <- PrefetchSubscription#add PrefetchSubscription#dispatchPending <- PrefetchSubscription#acknowledge PrefetchSubscription#dispatchPending <- DurableTopicSubscription#activate Because both #add (from Topic#send) and #acknowledge do the dispatch and compete with this "pendingLock" mutex, if a durable subscriber becomes busy doing huge dispatching (or huge expiration purging), Topic#send gets blocked and client will get unacceptable publishing latency. I wonder why publishing needs to be blocked by consuming in this way. Isn't there any way we can decouple the send request from the dispatching completely? asyncDispatch=true option doesn't really help at all, since that decouples only the transport part (from "dispatched" collection to client host) but not the actual paging-in part (from "pending" cursor to "dispatched" collection). Thanks, Jake -- View this message in context: http://activemq.2283324.n4.nabble.com/pendingLock-in-PrefetchSubscription-tp4672195.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
