Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: neutral (athena.apache.org: 216.139.250.139 is neither permitted
 nor denied by domain of jw@yahoo-inc.com)
Date: Wed, 2 Oct 2013 16:28:38 -0700 (PDT)
From: Jake Choi <jw@yahoo-inc.com>
To: users@activemq.apache.org
Message-ID: <1380756516201-4672195.post@n4.nabble.com>
Subject: pendingLock in PrefetchSubscription
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.