GridGain Clients
GridGain 9 clients connect to the cluster via a standard socket connection. Unlike in GridGain 8.x, there is no separate Thin and Thick clients in GridGain 9. All clients are 'thin'.
Clients do not become a part of the cluster topology, never hold any data, and are not used as a destination for compute calculations.
Client Connector Configuration
Client connection parameters are controlled by the client connector configuration. By default, GridGain accepts client connections on port 10800. You can change the configuration for the node by using the CLI tool at any time.
In GridGain 9, you can create and maintain configuration in either HOCON or JSON. The configuration file has a single root "node," called ignite. All configuration sections are children, grandchildren, etc., of that node. Here is what the client connector configuration looks like:
{
"ignite" : {
"clientConnector" : {
"connectTimeout" : 5000,
"idleTimeout" : 0,
"listenAddress" : "",
"metricsEnabled" : false,
"port" : 10800,
"sendServerExceptionStackTraceToClient" : false,
"ssl" : {
"ciphers" : "",
"clientAuth" : "none",
"enabled" : false,
"keyStore" : {
"password" : "********",
"path" : "",
"type" : "PKCS12"
},
"trustStore" : {
"password" : "********",
"path" : "",
"type" : "PKCS12"
}
}
}
}
}| Property | Default | Description | Changeable | Requires Restart | Acceptable Values |
|---|---|---|---|---|---|
connectTimeout |
5000 |
Connection attempt timeout, in milliseconds. |
Yes |
Yes |
0 - inf |
idleTimeout |
0 |
How long the client can be idle before the connection is dropped, in milliseconds. By default, there is no limit (0). |
Yes |
Yes |
0-2147483647 |
listenAddress |
"" |
Address (IP or hostname) to listen on. Listens on all interfaces if empty. |
Yes |
Yes |
Valid IP address or host name |
metricsEnabled |
false |
Defines if client metrics are collected. |
Yes |
Yes |
true, false |
port |
10800 |
The port the client connector will be listening to. |
Yes |
Yes |
1024-65535 |
sendServerExceptionStackTraceToClient |
false |
By default, only the exception message and code are sent back to the client. Set this property to true to include the full stack trace, which will appear as part of the client-side exception. |
Yes |
Yes |
true, false |
ssl.ciphers |
"" |
List of ciphers to enable, comma-separated. Empty for automatic cipher selection. |
Yes |
Yes |
TLS_AES_256_GCM_SHA384, etc. (standard cipher ids) |
ssl.clientAuth |
none |
Whether the SSL client authentication is enabled and whether it is mandatory. |
Yes |
Yes |
none, optional, require |
ssl.enabled |
false |
Defines if SSL is enabled. |
Yes |
Yes |
true, false |
ssl.keyStore.password |
** |
SSL keystore password. |
Yes |
Yes |
A valid password |
ssl.keyStore.path |
Path to the SSL keystore. |
Yes |
Yes |
A valid path |
|
ssl.keyStore.type |
PKCS12 |
Keystore type. |
Yes |
Yes |
PKCS12, JKS |
ssl.trustStore.password |
** |
Truststore password. |
Yes |
Yes |
A valid password |
ssl.trustStore.path |
Path to the truststore. |
Yes |
Yes |
A valid path |
|
ssl.trustStore.type |
PKCS12 |
Truststore type. |
Yes |
Yes |
PKCS12, JKS |
Here is how you can change the parameters:
node config update clientConnector.port=10469
Limitations
There are limitations to user types that can be used for such a mapping. Some limitations are common, and others are platform-specific due to the programming language used.
-
Only flat field structure is supported, meaning no nesting user objects. This is because GridGain tables, and therefore tuples have flat structure themselves;
-
Fields should be mapped to GridGain types;
-
All fields in user type should either be mapped to Table column or explicitly excluded;
-
All columns from Table should be mapped to some field in the user type;
-
Java only: Users should implement Mapper classes for user types for more flexibility;
Partition Awareness
In GridGain 9, partition awareness is enabled automatically for all clients.
Data in the cluster is distributed between the nodes in a balanced manner for scalability and performance reasons. Each cluster node maintains a subset of the data, and the partition distribution map, which is used to determine the node that keeps the primary/backup copy of requested entries.
Partition awareness allows the client to send query requests directly to the node that owns the queried data.
Without partition awareness, an application that is connected to the cluster via a client would execute all queries and operations via a single server node that acts as a proxy for the incoming requests. These operations would then be re-routed to the node that stores the data that is being requested. This would result in a bottleneck that could prevent the application from scaling linearly.
Notice how queries must pass through the proxy server node, where they are routed to the correct node.
With partition awareness in place, the client can directly route queries and operations to the primary nodes that own the data required for the queries. This eliminates the bottleneck, allowing the application to scale more easily.
Client Features
The following table outlines features supported by each client.
| Feature | Java | .NET | C++ |
|---|---|---|---|
Record Binary View |
yes |
yes |
yes |
Key-Value Binary View |
yes |
yes |
yes |
Record View |
yes |
yes |
yes |
Key-Value View |
yes |
yes |
yes |
SQL API |
yes |
yes |
yes |
Partition Awareness |
yes |
yes |
No |
Transactions |
yes |
yes |
yes |
Compute API |
yes |
yes |
yes |
Retry Policy |
yes |
yes |
No |
Heartbeats |
yes |
yes |
No |
Data Streamer |
yes |
yes |
No |
Continuous Query |
yes |
No |
yes |
© 2024 GridGain Systems, Inc. All Rights Reserved. Privacy Policy | Legal Notices. GridGain® is a registered trademark of GridGain Systems, Inc.
Apache, Apache Ignite, the Apache feather and the Apache Ignite logo are either registered trademarks or trademarks of The Apache Software Foundation.