[
http://jira.jboss.com/jira/browse/JBMESSAGING-1245?page=comments#action_1... ]
Tim Fox commented on JBMESSAGING-1245:
--------------------------------------
By inspection of the code I believe I can potential for a race condition which could cause
the observed problem.
In ServerConsumerEndpoint::handle()
if (sendCount == num)
{
//if change rate gets set to zero here then would get stuck!! ****
clientAccepting = false;
firstTime = false;
}
If a call to changeRate() comes in at line ****, then it is possible that sendCount gets
set to zero, and clientAccepting remains false, which would cause consumers to become
stuck
Workarounds for now woud be to set prefetchSize to a very large value so that TCP flow
control takes effect - although this may not be ideal.
Proper fix is to make sure those actions are properly synchronized.
Message delivery freezes with default values of prefetchSize and
slowConsumers
------------------------------------------------------------------------------
Key: JBMESSAGING-1245
URL:
http://jira.jboss.com/jira/browse/JBMESSAGING-1245
Project: JBoss Messaging
Issue Type: Bug
Reporter: Tim Fox
Assigned To: Tim Fox
Fix For: 1.4.0.SP3.CP02, 1.4.1.beta2
Message delivery seems to freeze under some circumstances with default values of
prefetchSize and slowConsumers.
Increasing the prefetchSize to 1000 seems to workaround the problem.
Waiting on customer to provide instructions for replication.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira