2

I wanted to understand the pro's/cons of using a client node within a cluster vs a external thin client. Ofcourse the thin client will be less chatty Vs a client node and hence less n/w interactions. Changes in the cluster topology(nodes adding/removing) would not affect the client, while it directly affects the client node.

All these make me wonder will a thin client always be a better option or are then other cases where having a client node makes much more sense.

If Apache/Gridgain has any documentation/links around this. That would do too.

TIA

Victor
  • 1,207
  • 2
  • 13
  • 21

2 Answers2

1

I think there won't be any thick client in future major releases; it will be superseded by a thin one instead because of a single protocol and lightweight design.

At the moment, a thick client still has some features advantage:

  • faster and better discovery and communication (topology changes)
  • peer class loading
  • near caching
  • advanced compute capabilities
  • events listening
  • full data structures support/distributed locking
  • etc

The feature parity list is constantly shrinking, but it's also worth mentioning that some features might be available for a particular platform only. For example, in .NET thin client, but not in Java one.

You have mentioned the cons already - being a cluster-wide citizen implies the same obligation a server node has. I.e. a good network channel and participation in all global events.

That means in some cases a thick client might not be deployed and working as expected. Usually it's about NAT, private networks, firewalls, and so on.

In general, I'd say if your task could be implemented by a thin client, use it. If a required feature/API is not yet available, consider using a thick one. For example, if you need something like a health-check for your application running every minute, you definitely would like to have a thin client for that task and not to trigger PME.

Alexandr Shapkin
  • 2,350
  • 1
  • 6
  • 10
  • If thick client is going to be superseded by thin client in next major releases. Then it does not make sense to go the think client route anyway. – Victor Feb 11 '23 at 01:23
  • Well, it's still under development and things may be changed. Plus, Apache 3.0/GridGain 9.0 is going to be positioned a bit differently and it will be a completely new product. As far as my understanding goes, it will be more about distributed database (Calcite SQL, columnar, etc) than a data grid with tons of features and APIs as it is in 2.x/8.x. – Alexandr Shapkin Feb 11 '23 at 12:02
  • So if you are going to use Ignite 2.x, and you need something from a thick client, feel free to use it, but remember about the limitations. – Alexandr Shapkin Feb 11 '23 at 12:03
0

Thick clients are aware of all nodes, data distribution, and are more efficient in most cases, use them if your deployment allows for it. Plus, thick clients support all of the GridGain APIs.

Thin clients are lightweight(similar to a jdbc driver), connect to the cluster via binary protocol with a well-defined message format, support a limited set of APIs, and allow for support of multiple languages: Java, .NET, C++, Python, Node.JS, and PHP are supported out of the box.

see docs on thin/thick clients differences
Also take a look at capabilities of thin clients.

This section explains how to choose a client.

For example, a thick client serves as a reducer for queries, thereby you avoid an extra hop(from server to thin client), and lessening the cluster load when executing a query on a partitioned cache.

A Thick client could also directly participate in compute jobs, usually it is used as a reducer, whereas a thin client just submits a job to the cluster.
A thick client could also receive event notifications. Thick clients could reconnect more reliably(because they know the current cluster state) if the cluster topology changes.

Alex K
  • 841
  • 4
  • 5