[ https://jira.jboss.org/jira/browse/JGRP-1119?page=com.atlassian.jira.plug... ] Bela Ban updated JGRP-1119: --------------------------- Fix Version/s: 2.9 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-1119?page=com.atlassian.jira.plug... ] Bela Ban commented on JGRP-1119: -------------------------------- One could argue that this is a configuration error: list only the instances which have JGroups running, e.g. TCPPING.initial_hosts="A[7800],B[7800],C[7800]", port_range="1" If there aren't any JGroups instances running on port 7800 at A, B or C, then that's a setup error. Not sure I want to fix this, possible fixes include: #1: - Make the socket use SO_TIMEOUT to read the length and version - If the length is > available memory: drop the message - If the version != our version: drop the message - Switch SO_TIMEOUT to 0 (block forever) and read the rest of the message #2: - Make the reading socket use SO_TIMEOUT in general, so the read doesn't hang, but returns after N seconds max Hmm, I don't really like either solution, but what we *could* do is a quick&dirty sanity check on length -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-1119?page=com.atlassian.jira.plug... ] Bela Ban commented on JGRP-1119: -------------------------------- Actually, I cannot reproduce this (with a simple program listening on one of the ports listed in initial_hosts): when JGroups connects to unknownservice:7800, and unknownservice is NOT a JGroups members, then the following happens: - JGroups will create a Connection to unknwownservice:7800 - The read will block - BasicTCP will destroy the connection to unknownservice:7800 because it is not part of the view Hmm, this is for joins, but TCPPING is also used by MERGE2, so what happens when no view is received ? Then the connection to unknownservice:7800 would linger around until the next view is received... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-1119?page=com.atlassian.jira.plug... ] Bela Ban commented on JGRP-1119: -------------------------------- Actually, I can't do this ! TCPConnectionMap is *generic*, and a send() doesn't need to ship a version number, so a read() cannot depend on it ! Reverting this change... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JGRP-1119?page=com.atlassian.jira.plug... ] Bela Ban commented on JGRP-1119: -------------------------------- This ends up being a mis-configuration issue: an admin must make sure that there are only JGroups services running within a given range. This shouldn't be an issue in a production system anyway, where ports are usually pinned down... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira