ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianfranco Murador <murador.gianfra...@gmail.com>
Subject Re: Finished IGNITE-901
Date Thu, 16 Jul 2015 19:23:47 GMT
Useful feature, a little note: When a new node id is setted , the local log
file is splitted into a new file , this setting is available with log4j2 .

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 <sboikov@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.*
> *            }*
> *        }*
> *    }*
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message