Hi Anton, There are a few thoughts on this :
1. I found this issue after I upgraded from 2.7.6 to 2.8.1 ( No timeout values etc has been changed in our application ). So for the same scenario and the same application configuration a. in 2.7.6 , the client receives a evt_node_segmented b. in 2.8.1 , the client receives a evt_node_reconnected. 2. >>>>it logs the event of client state updated from DISCONNECTED to RECONNECTED because the node succeeded to join the topology back within some time, the node was not segmented from the topology >From the logs I posted, it looks like client tries to reconnect using a new client id >>[tcp-client-disco-msg-worker-#4%client-null-igniteclient-SINGLE%] INFO org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi [] - Client node disconnected from cluster, will try to reconnect with new id 3. The logs also say >>Client node was reconnected after it was already considered failed by the server topology (this could happen after all servers restarted or due to a long network outage between the client and servers). All continuous queries and remote event listeners created by this client will be unsubscribed, consider listening to EVT_CLIENT_NODE_RECONNECTED event to restore them. If a client node reconnects after it was considered failed by server, shouldnt it receive a EVT_NODE_SEGMENTED ? regards, Veena. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
