Re-deploying a continuous query after all server nodes restart

classic Classic list List threaded Threaded
4 messages Options
DanieleBosetti DanieleBosetti
Reply | Threaded
Open this post in threaded view
|

Re-deploying a continuous query after all server nodes restart

Hi all,

I'd like to understand how to determine that a continuous query (CQ) needs
to be re-created, in case of multiple server restarts.

My understanding for the following case is:
if an ignite client joins a cluster (composed by server-A only) and  deploys
a CQ to the cluster, server-A will push updates to the client (CQ listens on
a cache with replicated mode).
When a new server node (server-B) joins the cluster, then that CQ is
deployed to the new server node.
Server-A will push updates for that CQ to the client, and when server-A
shuts down, then server-B will continue pushing updates for the CQ.
If server-A is started again, then the CQ is not re-deployed to this node
(does the client decide whether to re-deploy the CQ on new server nodes
based on their node-id ?)
If then server-B is shut down; I understand the CQ we originally created (or
the related client local listener), will stop receiving updates. (is that
correct?)

How can the client determine that no server is "managing" its CQ? (and,
since server nodes are restarted in turn, the client will not receive any
CLIENT_DISCONNECTED event)
Should the client listen to all NODE_JOIN and NODE_LEFT to figure out that
the servers left?

(I searched the examples section, but I couldn't find how to "keep alive" a
CQ).

Thanks!



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
ezhuravlev ezhuravlev
Reply | Threaded
Open this post in threaded view
|

Re: Re-deploying a continuous query after all server nodes restart

Hi,

In this case, starting the new node B and restarting the node A are absolutely the same - it's just starting the new node, because node A will be started with the new node id. As javadoc for CQ says:
Note that in case query is distributed and a new node joins, it will get the remote filter for the query during discovery process before it actually joins topology, so no updates will be missed.

So, in case of node restart, if at least one node has this CQ, it will be deployed to the newly joined node.

Evgenii

чт, 4 окт. 2018 г. в 19:16, DanieleBosetti <[hidden email]>:
Hi all,

I'd like to understand how to determine that a continuous query (CQ) needs
to be re-created, in case of multiple server restarts.

My understanding for the following case is:
if an ignite client joins a cluster (composed by server-A only) and  deploys
a CQ to the cluster, server-A will push updates to the client (CQ listens on
a cache with replicated mode).
When a new server node (server-B) joins the cluster, then that CQ is
deployed to the new server node.
Server-A will push updates for that CQ to the client, and when server-A
shuts down, then server-B will continue pushing updates for the CQ.
If server-A is started again, then the CQ is not re-deployed to this node
(does the client decide whether to re-deploy the CQ on new server nodes
based on their node-id ?)
If then server-B is shut down; I understand the CQ we originally created (or
the related client local listener), will stop receiving updates. (is that
correct?)

How can the client determine that no server is "managing" its CQ? (and,
since server nodes are restarted in turn, the client will not receive any
CLIENT_DISCONNECTED event)
Should the client listen to all NODE_JOIN and NODE_LEFT to figure out that
the servers left?

(I searched the examples section, but I couldn't find how to "keep alive" a
CQ).

Thanks!



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
DanieleBosetti DanieleBosetti
Reply | Threaded
Open this post in threaded view
|

Re: Re-deploying a continuous query after all server nodes restart

Hi, thanks for replying!

I double-checked my case, and (I was quite wrong); the client keeps
receiving updates from the CQ after the first server is restarted.
(maybe it could be useful to add a case in the examples section, like
"ContinuousQueryFailover"? I could try doing that eventually)


There is a thing that confuses me tough. I find the warning log below
("Client node was reconnected..") which advises to listen to
EVT_CLIENT_NODE_RECONNECTED.
Does that mean that simply listening to this event is enough for the client
to recover from the disconnection;
or is any further action required if we receive a
EVT_CLIENT_NODE_RECONNECTED (like closing the CQ and re-issuing it) ?
Also, even in presence of this message, my test case still passes (the CQ
keeps pushing data)-
so should I be worried when I see it?


"Client node was reconnected after it was already considered failed by the
server topology ..etc.." and
"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."


Thanks!



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
ezhuravlev ezhuravlev
Reply | Threaded
Open this post in threaded view
|

Re: Re-deploying a continuous query after all server nodes restart

Hi,

It may work in some cases, but it shouldn't work in case when client node was disconnected because all the server nodes were down. In this case, when client node will reconnect to the cluster, it will be completely new cluster, that doesn't know anything about old CQs. In this case, you should register CQ again.

Evgenii

пн, 8 окт. 2018 г. в 20:24, DanieleBosetti <[hidden email]>:
Hi, thanks for replying!

I double-checked my case, and (I was quite wrong); the client keeps
receiving updates from the CQ after the first server is restarted.
(maybe it could be useful to add a case in the examples section, like
"ContinuousQueryFailover"? I could try doing that eventually)


There is a thing that confuses me tough. I find the warning log below
("Client node was reconnected..") which advises to listen to
EVT_CLIENT_NODE_RECONNECTED.
Does that mean that simply listening to this event is enough for the client
to recover from the disconnection;
or is any further action required if we receive a
EVT_CLIENT_NODE_RECONNECTED (like closing the CQ and re-issuing it) ?
Also, even in presence of this message, my test case still passes (the CQ
keeps pushing data)-
so should I be worried when I see it?


"Client node was reconnected after it was already considered failed by the
server topology ..etc.." and
"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."


Thanks!



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/