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 <igor.belyako...@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 <npori...@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/ >> >
