Ignite Client Affinity Questions

[milkywayz <np...@bandwidth.com>]

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/

Re: Ignite Client Affinity Questions

[Denis Magda <dm...@gridgain.com>]

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 <ig...@gmail.com>
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 <np...@bandwidth.com> 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/
>>
>

Re: Ignite Client Affinity Questions

[Igor Belyakov <ig...@gmail.com>]

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 <np...@bandwidth.com> 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/
>