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/