Failover in thin client mode

classic Classic list List threaded Threaded
10 messages Options
kcheng.mvp kcheng.mvp
Reply | Threaded
Open this post in threaded view
|

Failover in thin client mode

From the document
https://apacheignite.readme.io/docs/java-thin-client-initialization-and-configuration

knows that ignite **thin** client mode failover is achieved by specified
multiple hosts(endpoints).



But I know there is a new feature called  IEP-23: Best Effort Affinity for
thin clients
<https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients>  

my understanding is that this new feature by sending  the cache commands to
the primary node of the key to improve the performance.

saying there is a cluster with 4 server nodes(a,b,c,d)

in the old fashion(without IEP-23), the service is available if there is at
least **One** server node is reachable.(for example: configure node-a,
node-b)

but the same case with IEP-23, how does the client knows the remained server
node in the cluster(ip address and port)? from java ignite thin client I
know a **Node ID** introduced, not I can not find the corresponding IP,
Port. from the document
https://apacheignite.readme.io/docs/java-thin-client-initialization-and-configuration
i can't find information about this.

As right now I am trying to implement an ignite go thin client, that's why I
ask the detail information.



 






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

Re: Failover in thin client mode

Hi,

I believe that this paragraph describes what you want to see:
Updating partition mapping

It is important for client to keep partition mapping updated. To ensure this, the following changes are proposed:

  1. Changes in Standard Message Response header. It is proposed to add flag to every response, that shows whether the Affinity Topology Version of the cluster has changed since the last request from the client.
  2. If the Affinity Topology Version of the cluster has changed since the last request from the client, new Affinity Topology Version is also included in the response.

Once client detects changes in the Affinity Topology, it does the following:

  1. Updates distributionMap and partitionMap (preferably asynchronously) for all active caches. It also may be done "on demand" - on the first call to the Cache instance;
  2. Tries to establish connection to hosts, which is not yet connected. This is required as changes of the topology may be caused by the new node joining the cluster.

More information is available on the wiki page.

Evgenii


чт, 25 апр. 2019 г. в 06:48, kcheng.mvp <[hidden email]>:
From the document
https://apacheignite.readme.io/docs/java-thin-client-initialization-and-configuration

knows that ignite **thin** client mode failover is achieved by specified
multiple hosts(endpoints).



But I know there is a new feature called  IEP-23: Best Effort Affinity for
thin clients
<https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients

my understanding is that this new feature by sending  the cache commands to
the primary node of the key to improve the performance.

saying there is a cluster with 4 server nodes(a,b,c,d)

in the old fashion(without IEP-23), the service is available if there is at
least **One** server node is reachable.(for example: configure node-a,
node-b)

but the same case with IEP-23, how does the client knows the remained server
node in the cluster(ip address and port)? from java ignite thin client I
know a **Node ID** introduced, not I can not find the corresponding IP,
Port. from the document
https://apacheignite.readme.io/docs/java-thin-client-initialization-and-configuration
i can't find information about this.

As right now I am trying to implement an ignite go thin client, that's why I
ask the detail information.










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

Re: Failover in thin client mode

Thank your information very much!



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

Re: Failover in thin client mode

Hello,

Are you developing a Go thin client? Can you share a link?

There is already one go client I'm aware of [1], is yours related somehow?

As for your question, thin client is given list of IPs and ports by a user. During the start,
or in background thin client tries to establish connection to all of them. Upon connection,
during handshake, it find outs node ID and associates it with given IP:port pair. Thin client
should not try to establish connection with any address, which is not given by a user.

Does it helps?


Best Regards,
Igor


On Thu, Apr 25, 2019 at 12:17 PM kcheng.mvp <[hidden email]> wrote:
Thank your information very much!



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

Re: Failover in thin client mode

This post was updated on .
Not sure my understanding is correct or not.
 There is the case when a new node join a cluster, if it's just as your said
then some key can not get directly from *the new added node*

I suppose it would work as below.

1: 5 node cluster(a,b,c,d,e)
2: even I just set two nodes/endpoints in the client configuration. upon the
first successfully hand-shark, the response should return all the nodes with
IP in the cluster.
3: clients try to connect other server node.


if the client just connect to the specified nodes/endpoints then for the
other un-specified nodes. it still need
an additional net hop.


what's more even I can specified all the server nodes in advance. then how the handle the case for adding a new server node? Need to stop the client and restart again?



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

Re: Failover in thin client mode

In reply to this post by Igor Sapego-1
I am still on the design phrase of go thin client. once it's ready I will share the link. thanks.
Thanks,
Ken Cheng


On Thu, Apr 25, 2019 at 10:02 PM Igor Sapego <[hidden email]> wrote:
Hello,

Are you developing a Go thin client? Can you share a link?

There is already one go client I'm aware of [1], is yours related somehow?

As for your question, thin client is given list of IPs and ports by a user. During the start,
or in background thin client tries to establish connection to all of them. Upon connection,
during handshake, it find outs node ID and associates it with given IP:port pair. Thin client
should not try to establish connection with any address, which is not given by a user.

Does it helps?


Best Regards,
Igor


On Thu, Apr 25, 2019 at 12:17 PM kcheng.mvp <[hidden email]> wrote:
Thank your information very much!



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

Re: Failover in thin client mode

The point of "Best effort" is that we do not guarantee every requested
to be routed to the optimal node, we only apply our best effort to make
this happen.

No, cluster will NOT return a address list to the client upon handshake
because.

1. It may be not secure to connect to nodes, which user did not specified
in the connection list.
2. It is not always possible, as client may be in a different network than
server nodes, so cluster nodes do not necessary know IPs of nodes, which
are valid for the client.

Best Regards,
Igor


On Thu, Apr 25, 2019 at 7:25 PM Ken Cheng <[hidden email]> wrote:
I am still on the design phrase of go thin client. once it's ready I will share the link. thanks.
Thanks,
Ken Cheng


On Thu, Apr 25, 2019 at 10:02 PM Igor Sapego <[hidden email]> wrote:
Hello,

Are you developing a Go thin client? Can you share a link?

There is already one go client I'm aware of [1], is yours related somehow?

As for your question, thin client is given list of IPs and ports by a user. During the start,
or in background thin client tries to establish connection to all of them. Upon connection,
during handshake, it find outs node ID and associates it with given IP:port pair. Thin client
should not try to establish connection with any address, which is not given by a user.

Does it helps?


Best Regards,
Igor


On Thu, Apr 25, 2019 at 12:17 PM kcheng.mvp <[hidden email]> wrote:
Thank your information very much!



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

Re: Failover in thin client mode

Thank your information very much!

Thanks,
Ken Cheng


On Fri, Apr 26, 2019 at 12:32 AM Igor Sapego <[hidden email]> wrote:
The point of "Best effort" is that we do not guarantee every requested
to be routed to the optimal node, we only apply our best effort to make
this happen.

No, cluster will NOT return a address list to the client upon handshake
because.

1. It may be not secure to connect to nodes, which user did not specified
in the connection list.
2. It is not always possible, as client may be in a different network than
server nodes, so cluster nodes do not necessary know IPs of nodes, which
are valid for the client.

Best Regards,
Igor


On Thu, Apr 25, 2019 at 7:25 PM Ken Cheng <[hidden email]> wrote:
I am still on the design phrase of go thin client. once it's ready I will share the link. thanks.
Thanks,
Ken Cheng


On Thu, Apr 25, 2019 at 10:02 PM Igor Sapego <[hidden email]> wrote:
Hello,

Are you developing a Go thin client? Can you share a link?

There is already one go client I'm aware of [1], is yours related somehow?

As for your question, thin client is given list of IPs and ports by a user. During the start,
or in background thin client tries to establish connection to all of them. Upon connection,
during handshake, it find outs node ID and associates it with given IP:port pair. Thin client
should not try to establish connection with any address, which is not given by a user.

Does it helps?


Best Regards,
Igor


On Thu, Apr 25, 2019 at 12:17 PM kcheng.mvp <[hidden email]> wrote:
Thank your information very much!



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

Re: Failover in thin client mode

This post was updated on .
In reply to this post by Igor Sapego-1
Hi Igor,

I just checked the jiras and found this IPE has not been implemented for
*java thin client* yet ? or I missed something?




https://issues.apache.org/jira/issues/?jql=project%20%3D%20Ignite%20AND%20labels%20IN%20(iep-23)%20ORDER%20BY%20status%20%20%20%20%20%20%20





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

Re: Failover in thin client mode

That's right. This IEP has been only implemented for C++ thin for now.

Best Regards,
Igor


On Fri, Apr 26, 2019 at 2:05 PM kcheng.mvp <[hidden email]> wrote:
Hi Igor,

I just checked the jiras and found this IPE has not been implemented for
*java thin client* yet ?



https://issues.apache.org/jira/issues/?jql=project%20%3D%20Ignite%20AND%20labels%20IN%20(iep-23)%20ORDER%20BY%20status%20%20%20%20%20%20%20





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