Oh, sure, I guess I need to be more precise. >From the “clustering” point of view (i.e. considering long-term connections >that hold the cluster together) the client has a single server that it is >connected to. The clustering part is handled by the Discovery SPI subsystem (and its default implementation TcpDiscoverySpi).
During the cluster lifetime there are peer-to-peer connections created between all nodes, clients and servers, which will transfer most of the data (all cache operations, etc). These connections are created and closed as needed. This is handled by the Communication SPI subsystem (and its default implementation TcpCommunicationSpi). What you see in the logs below is the client connecting to both servers to perform cache or other operations (note the TcpCommunicationSpi class), but only one server is responsible for making sure the client is connected and alive. About the documentation: I believe we don’t have this explained in detail yet, but some work is going on to improve the docs on networking in Ignite a bit – stay tuned. Thanks, Stan From: Bellenger, Dominique Sent: 19 марта 2018 г. 18:21 To: [email protected] Subject: AW: Question about client disco-/reconnect behaviour Hey Stan, thank you for your answer. Does there exist some form of documentation about that behaviour (besides the code itself of course 😊 ) My observations show that the client is indeed connecting to both servers. When both servers are running and I start the client I get the following output from the server logs: First try Server1: 15:15:00.0941|DEBUG|TcpCommunicationSpi|Accepted new client connection: /127.0.0.1:54587 15:15:00.0941|INFO |TcpCommunicationSpi|Accepted incoming communication connection [locAddr=/127.0.0.1:47100, rmtAddr=/127.0.0.1:54587] 15:15:00.1097|DEBUG|TcpCommunicationSpi|Sending local node ID to newly accepted session: GridSelectorNioSessionImpl [ ... ] 15:15:00.1097|DEBUG|TcpCommunicationSpi|Remote node ID received: 41d75cf0-a42e-48e2-b23f-61f1284bd189 15:15:00.1097|DEBUG|TcpCommunicationSpi|Received handshake message [locNodeId=584e9592-b423-4da4-a37d-f65e080473cf, rmtNodeId=41d75cf0-a42e-48e2-b23f-61f1284bd189, msg=HandshakeMessage2 [connIdx=0]] Server2: 15:15:02.1256|DEBUG|TcpCommunicationSpi|Accepted new client connection: /127.0.0.1:54588 15:15:02.1256|INFO |TcpCommunicationSpi|Accepted incoming communication connection [locAddr=/127.0.0.1:47101, rmtAddr=/127.0.0.1:54588] 15:15:02.1722|DEBUG|TcpCommunicationSpi|Sending local node ID to newly accepted session: GridSelectorNioSessionImpl [ ... ] 15:15:02.1892|DEBUG|TcpCommunicationSpi|Remote node ID received: 41d75cf0-a42e-48e2-b23f-61f1284bd189 15:15:02.1892|DEBUG|TcpCommunicationSpi|Received handshake message [locNodeId=2c190af0-113f-4a12-90a2-757b5ab89220, rmtNodeId=41d75cf0-a42e-48e2-b23f-61f1284bd189, msg=HandshakeMessage2 [connIdx=0]] Second try Server1: 16:12:18.1313|DEBUG|TcpCommunicationSpi|Accepted new client connection: /0:0:0:0:0:0:0:1:60600 16:12:18.1313|INFO |TcpCommunicationSpi|Accepted incoming communication connection [locAddr=/0:0:0:0:0:0:0:1:47101, rmtAddr=/0:0:0:0:0:0:0:1:60600] 16:12:18.1438|DEBUG|TcpCommunicationSpi|Sending local node ID to newly accepted session: GridSelectorNioSessionImpl [ ... ] 16:12:18.2365|DEBUG|TcpCommunicationSpi|Remote node ID received: f0c43cea-709d-420d-8c88-420a7ac3998d 16:12:18.2551|DEBUG|TcpCommunicationSpi|Received handshake message [locNodeId=465739c3-1c7c-4cb3-812b-de0c05315304, rmtNodeId=f0c43cea-709d-420d-8c88-420a7ac3998d, msg=HandshakeMessage2 [connIdx=0]] Server2: 16:12:17.8776|INFO |TcpCommunicationSpi|Accepted incoming communication connection [locAddr=/0:0:0:0:0:0:0:1:47100, rmtAddr=/0:0:0:0:0:0:0:1:60599] 16:12:17.8776|DEBUG|TcpCommunicationSpi|Sending local node ID to newly accepted session: GridSelectorNioSessionImpl [ ... ] 16:12:17.8916|DEBUG|TcpCommunicationSpi|Remote node ID received: f0c43cea-709d-420d-8c88-420a7ac3998d 16:12:17.9397|DEBUG|TcpCommunicationSpi|Received handshake message [locNodeId=be1a9f68-2e46-4e9f-8397-9b25a066d9cc, rmtNodeId=f0c43cea-709d-420d-8c88-420a7ac3998d, msg=HandshakeMessage2 [connIdx=0]] Note that using the exact same configuration the communication is established using IPv4 the first time and using IPv6 the second time. Dome Von: Stanislav Lukyanov <[email protected]> Gesendet: 19 March 2018 13:52 An: [email protected] Betreff: RE: Question about client disco-/reconnect behaviour Hi, Yes, that’s the expected behavior. The client is connected to a single server, not both. If the server it’s connected to is killed, the client will reconnect, producing the events in the process. When you kill one of the servers and the client doesn’t get disconnected it’s probably because you’ve killed the wrong one (not the one client is connected to). Stan From: Bellenger, Dominique Sent: 19 марта 2018 г. 15:32 To: [email protected] Subject: Question about client disco-/reconnect behaviour Hello igniters, I have a question about expected client reconnection behaviour. I have two server nodes and one client node. When everything is connected and one of the servers fails (because it is killed) the client is supposed to 1) Connect to the remaining server transparently, no Disconnect event, no reconnect event 2) Do nothing because it is connected to both servers and switches to the remaining connection silently. No Disconnect event, no Reconnect event. 3) Raise a disconnect event, connect to the remaining server, raise a reconnect event I observe the following behaviour and just wanted to know, if that is the expected one using Apache Ignite .NET 2.3 (also matches 2.4). If everything started I kill one of the server nodes and sometimes the client is disconnected and reconnects to the remaining server after a while. It does, however, not occur every time I kill one of the servers. In most cases I am successful forcing a reconnect if I do the following: - Start one server and the client (order doesn’t matter) - Start the second server and wait until everything is connected - Kill the first server - Client gets disconnected / reconnected - So: is that the desired behaviour? Thanks in advance, Dome
