Ignite Client Affinity Questions

classic Classic list List threaded Threaded
3 messages Options
milkywayz milkywayz
Reply | Threaded
Open this post in threaded view
|

Ignite Client Affinity Questions

Hello, I plan on using an Ignite node topology as follows:
1) Application configured as an Ignite Client that handles distributing
requests to the correct server node.
2) 3+ Partitioned Server nodes that handle cache storage and processing of
requests.
3) Each server node has two caches which use AffinityKey for pinning entries
in the two caches to one node for a given key.

Questions:
1) Will the client have up to date access to the AffinityFunction for the
two caches?
2) What sort of overhead is associated with running as client mode? I want
to make it as dumb as possible, so it would only just be aware of topology
changes and always have the latest AffinityFunction for the partitioned
server node topology.

Thank you, Nick.



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

Re: Ignite Client Affinity Questions

Hi Nick,

Yes, client node has up to date information regarding affinity and will use it to send request to the proper server node.

If you're comparing client node to thin client then client node has more overhead since it's starting cluster node and processes discovery and communication events in the cluster, due to that it has information regarding affinity. On the other hand, the thin client sends all requests to the same server node and after that the request will be redirected to other nodes if it's necessary.

Regards,
Igor



On Thu, Jul 25, 2019 at 6:37 PM milkywayz <[hidden email]> wrote:
Hello, I plan on using an Ignite node topology as follows:
1) Application configured as an Ignite Client that handles distributing
requests to the correct server node.
2) 3+ Partitioned Server nodes that handle cache storage and processing of
requests.
3) Each server node has two caches which use AffinityKey for pinning entries
in the two caches to one node for a given key.

Questions:
1) Will the client have up to date access to the AffinityFunction for the
two caches?
2) What sort of overhead is associated with running as client mode? I want
to make it as dumb as possible, so it would only just be aware of topology
changes and always have the latest AffinityFunction for the partitioned
server node topology.

Thank you, Nick.



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

Re: Ignite Client Affinity Questions

Folks, let me copy and paste a section from the new docs GridGain is working on and will launch soon. That section compares thick vs thin clients. Hopefully, it clarifies a lot.

Ignite/GridGain clients come in several different flavors, each with various capabilities. Thick and thin clients go beyond SQL capabilities and
support many more APIs. Finally, ORM frameworks like Spring Data or Hibernate are also integrated with GridGain and
can be used as an access point to your cluster.

Let's review the difference between thick and thin clients by comparing their capabilities.

*Thick* clients (aka. standard clients) join the cluster via an internal protocol, receive all of the cluster-wide
updates such as topology changes, are aware of data distribution, and can direct a query/operation to a server node
that owns a required data set. Plus, thick clients support all of the Ignite and GridGain APIs.

*Thin* clients (aka. lightweight clients) connect to the cluster via a public TCP/IP protocol with a well-defined
message format. This type of client supports a limited set of APIs (presently, key-value and SQL operations only) but
in return:

- Makes it easy to enable programming language support for GridGain and Ignite. Java, .NET, C++, Python, Node.JS, and
  PHP are supported out of the box.

- Doesn't have any dependencies on JVM. For instance, .NET and C++ _thick_ clients have a richer feature set but
  start and use JVM internally.

- Requires at least one port opened on the cluster end. Note, that more ports need to be opened if
  partition-awareness is used for a thin client.


--
Denis Magda


On Fri, Jul 26, 2019 at 6:21 AM Igor Belyakov <[hidden email]> wrote:
Hi Nick,

Yes, client node has up to date information regarding affinity and will use it to send request to the proper server node.

If you're comparing client node to thin client then client node has more overhead since it's starting cluster node and processes discovery and communication events in the cluster, due to that it has information regarding affinity. On the other hand, the thin client sends all requests to the same server node and after that the request will be redirected to other nodes if it's necessary.

Regards,
Igor



On Thu, Jul 25, 2019 at 6:37 PM milkywayz <[hidden email]> wrote:
Hello, I plan on using an Ignite node topology as follows:
1) Application configured as an Ignite Client that handles distributing
requests to the correct server node.
2) 3+ Partitioned Server nodes that handle cache storage and processing of
requests.
3) Each server node has two caches which use AffinityKey for pinning entries
in the two caches to one node for a given key.

Questions:
1) Will the client have up to date access to the AffinityFunction for the
two caches?
2) What sort of overhead is associated with running as client mode? I want
to make it as dumb as possible, so it would only just be aware of topology
changes and always have the latest AffinityFunction for the partitioned
server node topology.

Thank you, Nick.



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