[
http://jira.jboss.com/jira/browse/JGRP-499?page=comments#action_12361495 ]
Vladimir Blagojevic commented on JGRP-499:
------------------------------------------
Note that this timeout is not the timeout parameter configured at FLUSH protocol level.
There are two timeouts in FLUSH:
timeout configured at protocol level that represent the maximum time channel will be
blocking down messages irregardless of flush success. so even if something goes terribly
wrong with FLUSH channel will unblock channel.down() after timeout expires.
internal timeout that you are referring to is maximum timeout allowed for first FLUSH
phase to finish. First flush phase involves START_FLUSH, FLUSH_OK, FLUSH_COMPLETED
messages until the cluster becomes quiet. If FLUSH does not reach end of first flush phase
(due to flush collisions) then flush is repeated with simple back off algorithm.
JChannel.startFlush does not pass down timeout
----------------------------------------------
Key: JGRP-499
URL:
http://jira.jboss.com/jira/browse/JGRP-499
Project: JGroups
Issue Type: Bug
Affects Versions: 2.5
Reporter: Michael Newcomb
Assigned To: Vladimir Blagojevic
Fix For: 2.5
JChannel.startFlush() does not pass down the timeout in the Suspend event.
This causes a fixed timeout of 4000 to be used on flushes:
Flush.java:
case Event.SUSPEND:
return startFlush(evt, 4000, 5, false);
The SUSPEND event may or may not take a View as the arg, so, something will have to be
done to pass the timeout down. Perhaps a Map as the event arg with "timeout" and
"view" as possible keys?
--
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