[
http://jira.jboss.com/jira/browse/JGRP-590?page=comments#action_12375615 ]
Bela Ban commented on JGRP-590:
-------------------------------
The above description is not correct: when we block on credits, as soon as we have
received credits, we actually do send the blocked message, but the credits might become
negative. Example:
- credits=50000
- we send message M1 with 70000 bytes
- we block until new credits are received
- even if the new credits + remaining credits are 50000, we *send* the message
- now (remaining) credits are -20000
- the next message will block again
So, while we don't block forever, we should still implement the proposed changes, as
they prevent misconfiguration, and too many blockings due to messages which are too large
FC: messages > max_credits will block forever
---------------------------------------------
Key: JGRP-590
URL:
http://jira.jboss.com/jira/browse/JGRP-590
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6, 2.5.1, 2.4.1 SP5
FC.down checks for the message size. If that size is greater than the credits left, we
block until we get more credits from the receiver(s). However, if the message size is
greater than *max_credits*, we will *never* have more than max_credits available to send
the message, so we'd block forever !
To prevent running into this, we need to check (at startup time) in FC that
- a fragmentation protocol is available (somewhere above the FC protocol)
- that the max fragmentation size of the fragmentation protocol is smaller than
max_credits
We should also log a (fatal) error message if we receive a message whose size is greater
than max_credits (this should *not* happen anymore though after the proposed change above)
--
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