Conversation
✅ Deploy Preview for hardcore-allen-f5257d ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| .Stream processing | ||
| [%collapsible] | ||
| ==== | ||
| Applies to Java and Python Jet jobs only. |
There was a problem hiding this comment.
Python Jet jobs can only define a mapping. They don't have access to Jet pipeline.
| |=== | ||
| ==== | ||
|
|
||
| .Data structures |
There was a problem hiding this comment.
Will this be the source of truth for feature support between clients?
If not, maybe we should consider linking to the source of truth.
| |=== | ||
| ==== | ||
|
|
||
| .Concurrency primitives |
There was a problem hiding this comment.
CPMap is missing in this section
There was a problem hiding this comment.
Good catch. Can you list the client support for CPMap?
There was a problem hiding this comment.
Java Client, Go Client, and .Net client are the ones that support it.
| |SQL | ||
| |icon:circle-check[size=lg,role=success] | ||
| |icon:circle-check[size=lg,role=success] | ||
| |icon:circle-xmark[size=lg,role=error] |
| |=== | ||
| ==== | ||
|
|
||
| .Networking |
There was a problem hiding this comment.
The unisocket vs smart client thing changed a bit.
There's now the "routing modes":
https://docs.hazelcast.com/hazelcast/5.6/clients/java#client-cluster-routing-modes
I believe besides the Java client, .Net and C++ clients support it.
cc: @ihsandemir @emreyigit
| |icon:circle-xmark[size=lg,role=error] | ||
| |icon:circle-xmark[size=lg,role=error] | ||
|
|
||
| |Client-side statistics |
There was a problem hiding this comment.
You tell me 🙂
| |icon:circle-check[size=lg,role=success] | ||
| |icon:circle-check[size=lg,role=success] | ||
| |icon:circle-check[size=lg,role=success] | ||
| |icon:circle-xmark[size=lg,role=error] |
There was a problem hiding this comment.
Go client has near cache stats.
| |Client runtime stats | ||
| |icon:circle-check[size=lg,role=success] | ||
| |icon:circle-check[size=lg,role=success] | ||
| |icon:circle-xmark[size=lg,role=error] |
There was a problem hiding this comment.
N/A may be more appropriate for the C++ client.
cc: @ihsandemir
There was a problem hiding this comment.
not available at the moment for C++
| |Client operating systems stats | ||
| |icon:circle-check[size=lg,role=success] | ||
| |icon:circle-check[size=lg,role=success] | ||
| |icon:circle-xmark[size=lg,role=error] |
There was a problem hiding this comment.
@ihsandemir Doesn't the C++ client provide OS statS?
|
|
||
| * Lower latency: for data kept in the embedded member, embedded mode offers faster data access because applications do not need to send requests to the cache cluster over the network | ||
| * Simplicity: for Java applications, embedded mode is simpler to set up and use, because you only need to add the Hazelcast JAR to your classpath | ||
| * Lower latency: for data kept in the embedded member, embedded mode offers faster data access because applications do not need to send requests to the cache cluster over the network. |
There was a problem hiding this comment.
Wrong!!! members communicate. In some cases, client will be faster.
E.g. you do IMap.put,
-
client sends it directly to partition owner member and gets back the response.
-
Embedded API: member prepares and operation and serializes and send it to the partition owning member.
There was a problem hiding this comment.
Interesting. Is serialization the difference there? It needs to pass between nodes in either case (assuming the partition owner isn't the member receiving the PUT in embedded mode), but there's no serialization/deserialization in client/member communication? But inter-member communication is always serialized?
There was a problem hiding this comment.
E.g. we do use back acks feature, so that the clıent completes the operation by just receiving the ack from the backup server, which speeds up the response.
E.g. if the server is too busy responding to other ops, it will slow down.
| * Lower latency: for data kept in the embedded member, embedded mode offers faster data access because applications do not need to send requests to the cache cluster over the network. | ||
| * Simplicity: for Java applications, embedded mode is simpler to set up and use, because you only need to add the Hazelcast JAR to your classpath. | ||
|
|
||
| ==== Disadvantages |
There was a problem hiding this comment.
One disadvantage: Each embedded application means a new member joining the cluster and if the application ends it leaves the cluster. In these stages, the partition redistribution and a lot more takes place between the members. Hence, embedded member start is more heavier process compared to starting a client app.
| * Coupled scaling: in embedded mode, the application and the cluster must be scaled together, which is not suitable for all use cases. | ||
| * Less flexibility: Hazelcast members scale with your application instances, which may be inefficient. | ||
|
|
||
| TIP: Hazelcast offers a xref:clients:java.adoc#configuring-client-near-cache[Near Cache] feature for clients that can reduce latency in client/server mode by storing frequently used data in the client's local memory. |
There was a problem hiding this comment.
Partıally wrong, near cache also exists for embedded API.
| NOTE: Hazelcast offers a xref:clients:java.adoc#configuring-client-near-cache[Near Cache] feature for clients which can reduce latency in client/server mode by storing frequently used data in the client's local memory. | ||
|
|
||
| == Next steps | ||
| == Choose a client |
There was a problem hiding this comment.
| == Choose a client | |
| == Client Feature Support by Programming Language |
| @@ -1,80 +1,896 @@ | |||
| = Overview | |||
| :description: Overview of the main Hazelcast clients and APIs | |||
| :description: Hazelcast provides clients and APIs to interact with Hazelcast clusters and leverage their distributed computing capabilities. The choice of client or API depends on your use case and the programming languages you're using in your project. | |||
There was a problem hiding this comment.
| :description: Hazelcast provides clients and APIs to interact with Hazelcast clusters and leverage their distributed computing capabilities. The choice of client or API depends on your use case and the programming languages you're using in your project. | |
| :description: Hazelcast provides APIs to interact with Hazelcast clusters and leverage their distributed computing capabilities. Some language APIs require the language libraries(client libraries). For Java language, there are two APIs, one that uitlizes the Java client and the other that starts and embedded server instance and uses the same APIs as the client to interact with the cluster. For non-Java clients, the only wat to interact is using the client library for that language. The client talks to the cluster using the Hazelcast Open Binary client protocol. | |
| There are also two other was to interact with the Hazelcast cluster: | |
| - memcache API: You can use the Java memcache library and Hazelcast implements the memcache API. | |
| - REST API |
|
|
||
| The maximum recommended number of clients per member is 100. | ||
| Members use different executors, each with a different thread count, for handling different types of client message tasks: | ||
| The maximum number of clients you can connect depends on your environment and workload. Members use different executors, each with a different thread count, for handling different types of client message tasks: |
There was a problem hiding this comment.
| The maximum number of clients you can connect depends on your environment and workload. Members use different executors, each with a different thread count, for handling different types of client message tasks: | |
| The maximum number of clients you can connect depends on your environment and workload. | |
| Members use different executors, each with a different thread count, for handling different types of client message tasks: |
| * xref:nodejs.adoc[Node.js] | ||
|
|
||
| * More complex setup: client/server mode requires setting up and managing a separate Hazelcast cluster, which can be more complex than embedding Hazelcast directly in your application | ||
| For information about the client protocol, see the link:https://github.com/hazelcast/hazelcast-client-protocol[client protocol repository]. |
There was a problem hiding this comment.
We discussed that we do not totally remove the client protocol doc sections but have the first sections at the ref manual and perhaps direct to the repo message definitions for further details. Will you do it?
There was a problem hiding this comment.
Not in this PR. PM didn't want it in the main documentation so will need to discuss it again. In the meantime, it's available in the client protocol repo.
|
|
||
| |Semaphore | ||
| |icon:circle-check[size=lg,role=success] | ||
| |icon:circle-xmark[size=lg,role=error] |
There was a problem hiding this comment.
.NET client supports CP Semaphore.
|
|
||
| |CountDownLatch | ||
| |icon:circle-check[size=lg,role=success] | ||
| |icon:circle-xmark[size=lg,role=error] |
There was a problem hiding this comment.
.NET client supports CountDownLatch
6 participants
Import https://hazelcast.com/developers/clients/ into the documentation.
Preview: https://deploy-preview-2070--hardcore-allen-f5257d.netlify.app/hazelcast/5.7-snapshot/clients/client-overview#choose-a-client