Setting Up Client Network¶
Main parts of network related configuration for Hazelcast Python client may be tuned via the arguments described in this section.
Here is an example of configuring the network for Python client.
client = hazelcast.HazelcastClient( cluster_members=[ "10.1.1.21", "10.1.1.22:5703" ], smart_routing=True, redo_operation=False, connection_timeout=6.0 )
Providing Member Addresses¶
Address list is the initial list of cluster addresses which the client will connect to. The client uses this list to find an alive member. Although it may be enough to give only one address of a member in the cluster (since all members communicate with each other), it is recommended that you give the addresses for all the members.
client = hazelcast.HazelcastClient( cluster_members=[ "10.1.1.21", "10.1.1.22:5703" ] )
If the port part is omitted, then ports
be tried in a random order.
You can specify multiple addresses with or without the port information
as seen above. The provided list is shuffled and tried in a random
order. Its default value is
Setting Smart Routing¶
Smart routing defines whether the client mode is smart or unisocket. See the Python Client Operation Modes section for the description of smart and unisocket modes.
client = hazelcast.HazelcastClient( smart_routing=True, )
Its default value is
True (smart client mode).
Enabling Redo Operation¶
It enables/disables redo-able operations. While sending the requests to
the related members, the operations can fail due to various reasons.
Read-only operations are retried by default. If you want to enable retry
for the other operations, you can set the
client = hazelcast.HazelcastClient( redo_operation=False )
Its default value is
Setting Connection Timeout¶
Connection timeout is the timeout value in seconds for the members to accept the client connection requests.
client = hazelcast.HazelcastClient( connection_timeout=6.0 )
Its default value is
Enabling Client TLS/SSL¶
You can use TLS/SSL to secure the connection between the clients and members. If you want to enable TLS/SSL for the client-cluster connection, you should set the SSL configuration. Please see the TLS/SSL section.
As explained in the TLS/SSL section, Hazelcast members have key stores used to identify themselves (to other members) and Hazelcast Python clients have certificate authorities used to define which members they can trust. Hazelcast has the mutual authentication feature which allows the Python clients also to have their private keys and public certificates, and members to have their certificate authorities so that the members can know which clients they can trust. See the Mutual Authentication section.
Enabling Hazelcast Viridian Discovery¶
Hazelcast Python client can discover and connect to Hazelcast clusters
running on Hazelcast Viridian. For this,
provide authentication information as
cluster_name and enable Viridian
discovery by setting your
cloud_discovery_token as shown below.
client = hazelcast.HazelcastClient( cluster_name="name-of-your-cluster", cloud_discovery_token="discovery-token" )
If you have enabled encryption for your cluster, you should also enable TLS/SSL configuration for the client to secure communication between your client and cluster members as described in the TLS/SSL for Hazelcast Python Clients section.
External Smart Client Discovery¶
This feature requires Hazelcast 4.2 or higher version.
The client sends requests directly to cluster members in the smart client mode (default) in order to reduce hops to accomplish operations. Because of that, the client should know the addresses of members in the cluster.
In cloud-like environments, or Kubernetes, there are usually two network interfaces: the private and public network interfaces. When the client is in the same network as the members, it uses their private network addresses. Otherwise, if the client and the Hazelcast cluster are on different networks, the client cannot connect to members using their private network addresses. Hazelcast 4.2 introduced External Smart Client Discovery to solve that issue. The client needs to communicate with all cluster members via their public IP addresses in this case. Whenever Hazelcast cluster members are able to resolve their own public external IP addresses, they pass this information to the client. As a result, the client can use public addresses for communication.
In order to use this feature, make sure your cluster members are accessible
from the network the client resides in, then set
configuration option to
True while constructing the client. You should also
specify the public address of at least one member in the configuration:
client = hazelcast.HazelcastClient( cluster_members=["myserver.publicaddress.com:5701"], use_public_ip=True, )
This solution works everywhere without further configuration (Kubernetes, AWS, GCP, Azure, etc.) as long as the corresponding plugin is enabled in Hazelcast server configuration.
Configuring Backup Acknowledgment¶
When an operation with sync backup is sent by a client to the Hazelcast member(s), the acknowledgment of the operation’s backup is sent to the client by the backup replica member(s). This improves the performance of the client operations.
To disable backup acknowledgement, you should use the
backup_ack_to_client_enabled configuration option.
client = hazelcast.HazelcastClient( backup_ack_to_client_enabled=False, )
Its default value is
True. This option has no effect for unisocket
You can also fine-tune this feature using the config options as described below:
operation_backup_timeout: Default value is
5seconds. If an operation has backups, this property specifies how long the invocation waits for acks from the backup replicas. If acks are not received from some of the backups, there will not be any rollback on the other successful replicas.
fail_on_indeterminate_operation_state: Default value is
False. When it is
True, if an operation has sync backups and acks are not received from backup replicas in time, or the member which owns primary replica of the target partition leaves the cluster, then the invocation fails. However, even if the invocation fails, there will not be any rollback on other successful replicas.