-
-
prevent loading cluster node details from repository if it would resolve to local instance;
-
terminate tigase instance if in cluster-mode it resolve it's hostname to 'localhost';
-
terminate incoming cluster connections if they for some reason came from the same instance (highly unlikely, but to be on the safe side);
-
-
Code review comments.
I looked in the ClusterConnectionManager changes and I am not sure if the condition is correct (maybe I misunderstand the code):
// we ignore any local addresses if (!addr.isAnyLocalAddress() && !addr.isLoopbackAddress() && !( NetworkInterface.getByInetAddress( addr ) != null ) ){ log.log( Level.WARNING, "Cluster handshake received from this instance, terminating: {0}", serv_addr ); return; }Shouldn't it be actually like this?
// we ignore any local addresses if (addr.isAnyLocalAddress() || addr.isLoopbackAddress() || ( NetworkInterface.getByInetAddress( addr ) == null ) ){ log.log( Level.WARNING, "Cluster handshake received from this instance, terminating: {0}", serv_addr ); return; } -
Another comment, similar, but related to ClConConfigRepository modifications.
Piece of code:
isCorrect = !addr.isAnyLocalAddress() && !addr.isLoopbackAddress() && !( NetworkInterface.getByInetAddress( addr ) != null );I think the last condition should be different, either remove '!' or use '==' for null testing:
isCorrect = !addr.isAnyLocalAddress() && !addr.isLoopbackAddress() && ( NetworkInterface.getByInetAddress( addr ) != null ); -
-
NetworkInterface.getByInetAddress( addr ) != nullindicates that given address is local (it's matched against any of the local interfaces) hence the condition inClConConfigRepositoryis (was*) correct; -
ClusterConnectionManageris indeed wrong - condition logic is inverted in comparison toClConConfigRepositoryfrom where it was taken - this was corrected; -
(*) I've reverted the behaviour of
ClConConfigRepository.clusterRecordValid()to previous state and moved the check toClusterConnectionManager.itemAdded()as, apart from obviously wrong cluster items like @localhost@, we still need to load all valid cluster items in order to proceed with the password handshake.
Tested on our test-cluster.
-
| Type |
Bug
|
| Priority |
Normal
|
| Assignee | |
| RedmineID |
2014
|
| Version |
tigase-server-7.0.0
|
| Spent time |
0
|
Avoid establishing cluster connection to the node itself to avoid connectivity issues (i.e. source = target IP(s) of the machine)