-
-
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 ) != null
indicates that given address is local (it's matched against any of the local interfaces) hence the condition inClConConfigRepository
is (was*) correct; -
ClusterConnectionManager
is indeed wrong - condition logic is inverted in comparison toClConConfigRepository
from 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)