[ http://jira.jboss.com/jira/browse/JGRP-717?page=all ] Bela Ban resolved JGRP-717. --------------------------- Resolution: Done added xmit_off (default: false) in 2.6 and CVS head (2.7) -- 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

[ http://jira.jboss.com/jira/browse/JGRP-717?page=comments#action_12417506 ] Bela Ban commented on JGRP-717: ------------------------------- Using xmit_off makes no sense: [Vladimir] - Members A and B - Member B before becoming a member in a view sends a unicast as a part of discovery to A - In B we create an entry in UNICAST for target A, sequence number 1 - Say a view V without B is first installed at A (remember this is highly concurrent situation with multiple node startup) - The new view V installation at A tears down the connection B made to A in UNICAST *and* TCP ! - B sends a message (say new OOB discovery) with seq number 2 but since the connection at the TCP level from B to A was we get that "127.0.0.1:7802 failed sending data to 127.0.0.1:7800: java.net.SocketException: Socket closed" but UNICAST at B considers message 2 to be sent without a hitch ( we do not propagate exception to UNICAST layer) - Say next time B sends a discovery message it succeeds (that connection table entry is now removed and a new connection is created) - The OOB from B will go up the stack at A but no regular message will since we have a sequence gap. ==> Kaboom! The regular unicast from B to A never gets delivered at A! -- 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

[ http://jira.jboss.com/jira/browse/JGRP-717?page=comments#action_12417509 ] Bela Ban commented on JGRP-717: ------------------------------- [Bela] Aha, the reason for the exception on send() is we DON'T remove the connection at B when A closes its side ! In BasicConnectionTable:684 you can see that remove() is commented. The reason for this was that members could get into a state where the mutually close their connections to each other, and so I thought it was better to let them close the connections just-in-time when data was sent. But you're right: one tiny little exception sending data and we end up with a lost sequence number, and thus a stuck receiver. I'll remove xmit_off -- 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