You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Semyon Boikov <sb...@gridgain.com> on 2015/07/16 13:29:02 UTC
Finished IGNITE-901
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.*
* }*
* }*
* }*
Re: Finished IGNITE-901
Posted by Semyon Boikov <sb...@gridgain.com>.
Added documentation about client reconnect in the 'Clients vs Servers'
section: http://apacheignite.readme.io/docs/clients-vs-servers.
On Thu, Jul 16, 2015 at 2:29 PM, Semyon Boikov <sb...@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.*
> * }*
> * }*
> * }*
>
>
Re: Finished IGNITE-901
Posted by Gianfranco Murador <mu...@gmail.com>.
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 <sb...@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.*
> * }*
> * }*
> * }*
>
Re: Finished IGNITE-901
Posted by Semyon Boikov <sb...@gridgain.com>.
> 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 <ds...@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 <sb...@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.*
> > * }*
> > * }*
> > * }*
> >
>
Re: Finished IGNITE-901
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <sb...@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.*
> * }*
> * }*
> * }*
>