> A couple of additional questions: > 1. I am assuming that near caches are dropped on reconnect as well, right? Right, content of near caches is dropped on reconnect.
> 2. Do we have documentation for this feature? If not, can we add this > documentation to the client section? Not yet, will try to add documentation today. > 3. Did this feature in any way affect ability to start many (100+) clients > in the same JVM? No, this feature did not add any additional overhead. On Thu, Jul 16, 2015 at 7:32 PM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > Great job, Semyon! > > This is a very useful feature and is a huge addition to the project, as it > adds self-healing capabilities to our cluster. I was following this > development from the sidelines and want to mention that this feature is > very well tested, with many unit tests added to CI, as well as many manual > tests that occurred. > > A couple of additional questions: > 1. I am assuming that near caches are dropped on reconnect as well, right? > 2. Do we have documentation for this feature? If not, can we add this > documentation to the client section? > 3. Did this feature in any way affect ability to start many (100+) clients > in the same JVM? > > Thanks, > D. > > On Thu, Jul 16, 2015 at 4:29 AM, Semyon Boikov <sboi...@gridgain.com> > wrote: > > > Hi, > > > > I finished work on 'client reconnect' feature ( > > https://issues.apache.org/jira/browse/IGNITE-901), it is merged into > > master. Here is brief description of this feature: > > > > Client node can disconnect from cluster in several cases: > > - in case of network problems when client can not re-establish connection > > with server > > - connection with server was broken for some time, client is able to > > re-establish connection with server, but server already dropped client > node > > since did not receive client heartbeats > > - slow clients can be dropped by server (see > > TcpCommunicationSpi.slowClientQueueLimit) > > > > Before changes done in ignite-901 in case of disconnection client node > was > > just stopped. > > > > Now client assigns to a local node new ID and tries to reconnect to > > cluster. Note: this has side effect and 'id' property of local > ClusterNode > > will change in case of client reconnection. > > While client tries to reconnect to cluster all Ignite API throws special > > exception: IgniteClientDisconnectedException, this exception provides > > future which will be completed when client finish reconnect (IgniteCache > > API throws CacheException which has IgniteClientDisconnectedException as > > its cause). > > > > After client reconnected Ignite API can be used again. > > > > Also we added special discovery events > > (EventType.EVT_CLIENT_NODE_DISCONNECTED, > > EventType.EVT_CLIENT_NODE_RECONNECTED) and method on IgniteCluster to get > > client reconnect future. > > > > New reconnect behavior can be disabled using 'clientReconnectDisabled' > > property on TcpDiscoverySpi. > > > > And here is an example how work with disconnected exception looks like: > > > > * IgniteCache cache = ignite.getOrCreateCache(new > > CacheConfiguration<>());* > > > > * while (true) {* > > * try {* > > * cache.put(key, val);* > > * }* > > * catch (CacheException e) {* > > * if (e.getCause() instanceof > IgniteClientDisconnectedException) > > {* > > * IgniteClientDisconnectedException cause = > > (IgniteClientDisconnectedException)e.getCause();* > > > > * cause.reconnectFuture().get();* > > > > * // Client reconnected, can proceed and use the same > cache > > instance.* > > * }* > > * }* > > * }* > > >
