.hazelcast.5.1-BETA-1.source-code.hazelcast-config-5.0.xsd Maven / Gradle / Ivy
To use Hazelcast Enterprise, you need to set the license key here or programmatically.
Controls if missing replacement value should lead to stop the boot process.
Metadata policy for this map. Hazelcast may process objects of supported types ahead of time to
create additional metadata about them. This metadata then is used to make querying and indexing faster.
Metadata creation may decrease put throughput.
Valid values are:
CREATE_ON_UPDATE (default): Objects of supported types are pre-processed when they are created and updated.
OFF: No metadata is created.
Data type used to store entries.
Possible values:
BINARY (default): keys and values are stored as binary data.
OBJECT: values are stored in their object forms.
NATIVE: keys and values are stored in native memory. Only available on Hazelcast Enterprise.
True (default) if statistics gathering is enabled on the map, false otherwise.
False (default) if per entry stats gathering is disabled on the map, true otherwise.
Control caching of de-serialized values. Caching makes query evaluation faster, but it cost memory.
Possible Values:
NEVER: Never cache de-serialized object
INDEX-ONLY: Cache values only when they are inserted into an index.
ALWAYS: Always cache de-serialized values.
Number of synchronous backups. For example, if 1 is set as the backup-count,
then all entries of the map will be copied to one other JVM for
fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
Number of asynchronous backups. For example, if 1 is set as the backup-count,
then all entries of the map will be copied to one other JVM for
fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
Maximum number of seconds for each entry to stay in the map. Entries that are
older than <time-to-live-seconds> and are not updated for <time-to-live-seconds>
are automatically evicted from the map.
Any integer between 0 and Integer.MAX_VALUE. 0 means infinite. Default is 0.
Maximum number of seconds for each entry to stay idle in the map. Entries that are
idle(not touched) for more than <max-idle-seconds> are
automatically evicted from the map. The entry is touched if get, put or containsKey is called.
Any integer between 0 and Integer.MAX_VALUE. 0 means infinite. Default is 0.
When maximum size is reached, map is evicted based on the eviction policy.
IMap has no eviction by default.
size:
maximum size can be any integer between 0 and Integer.MAX_VALUE.
For max-size to work, set the eviction-policy property to a value other than NONE.
Default value is 0.
max-size-policy:
max-size-policy has these valid values:
PER_NODE: Maximum number of map entries in each Hazelcast instance.
This is the default policy.
PER_PARTITION: Maximum number of map entries within each partition. Storage size
depends on the partition count in a Hazelcast instance.
This attribute should not be used often.
Avoid using this attribute with a small cluster: if the cluster is small it will
be hosting more partitions, and therefore map entries, than that of a larger
cluster. Thus, for a small cluster, eviction of the entries will decrease
performance (the number of entries is large).
USED_HEAP_SIZE: Maximum used heap size in megabytes per map for each Hazelcast instance.
USED_HEAP_PERCENTAGE: Maximum used heap size percentage per map for each Hazelcast
instance.
If, for example, JVM is configured to have 1000 MB and this value is 10, then the map
entries will be evicted when used heap size exceeds 100 MB.
FREE_HEAP_SIZE: Minimum free heap size in megabytes for each JVM.
FREE_HEAP_PERCENTAGE: Minimum free heap size percentage for each JVM.
For example, if JVM is configured to have 1000 MB and this value is 10,
then the map entries will be evicted when free heap size is below 100 MB.
USED_NATIVE_MEMORY_SIZE: Maximum used native memory size in megabytes per map
for each Hazelcast instance.
USED_NATIVE_MEMORY_PERCENTAGE: Maximum used native memory size percentage per map
for each Hazelcast instance.
FREE_NATIVE_MEMORY_SIZE: Minimum free native memory size in megabytes
for each Hazelcast instance.
FREE_NATIVE_MEMORY_PERCENTAGE: Minimum free native memory size percentage
for each Hazelcast instance.
eviction-policy:
Eviction policy has these valid values:
LRU (Least Recently Used),
LFU (Least Frequently Used),
RANDOM,
NONE.
Default value is "NONE".
True if reading local backup entries is enabled, false otherwise.
Adds the Split Brain Protection for this data-structure which you configure using the split-brain-protection element.
You should set the split-brain-protection-ref's value as the split brain protection's name.
Name of the map.
If true, previously assigned values for the affected keys will be sent to this
cache-entry-listener implementation. Setting this attribute to true
creates additional traffic. Default value is false.
If true, this cache-entry-listener implementation will be called
in a synchronous manner. Default value is false.
The fully qualified class name of the cache key type.
The fully qualified class name of the cache value type.
True if statistics gathering is enabled on the cache, false (default) otherwise.
True if management is enabled on the cache, false (default) otherwise.
True if read-through caching is used, false (default) otherwise.
True if write-through caching is used, false (default) otherwise.
The cache loader factory class name.
The cache loader class name.
The cache writer factory class name.
The cache writer class name.
Defines the expiry policy factory class name or
defines the expiry policy factory from predefined ones with duration configuration.
List of cache entry listeners.
Data type used to store entries.
Possible values:
BINARY (default): keys and values are stored as binary data.
OBJECT: values are stored in their object forms.
NATIVE: keys and values are stored in native memory. Only available on Hazelcast Enterprise.
Number of synchronous backups. For example, if `1` is set as the `backup-count`,
then all entries of the cache are copied to one other instance as synchronous for fail-safety.
`backup-count` + `async-backup-count` cannot be bigger than maximum backup count which is `6`.
Valid numbers are 0 (no backup), 1, 2 ... 6.
Number of asynchronous backups. For example, if `1` is set as the `async-backup-count`,
then all entries of the cache are copied to one other instance as asynchronous for fail-safety.
`backup-count` + `async-backup-count` cannot be bigger than maximum backup count which is `6`.
Valid numbers are 0 (no backup), 1, 2 ... 6.
When maximum size is reached, cache is evicted based on the eviction policy.
size:
maximum size can be any integer between 0 and Integer.MAX_VALUE.
Default value is 0.
max-size-policy:
max-size-policy has these valid values:
ENTRY_COUNT (Maximum number of cache entries in the cache),
USED_NATIVE_MEMORY_SIZE (Maximum used native memory size in megabytes per cache for each Hazelcast
instance),
USED_NATIVE_MEMORY_PERCENTAGE (Maximum used native memory size percentage per cache for each Hazelcast
instance),
FREE_NATIVE_MEMORY_SIZE (Maximum free native memory size in megabytes for each Hazelcast instance),
FREE_NATIVE_MEMORY_PERCENTAGE (Maximum free native memory size percentage for each Hazelcast instance).
Default value is "ENTRY_COUNT".
eviction-policy:
Eviction policy has these valid values:
LRU (Least Recently Used),
LFU (Least Frequently Used).
Default value is "LRU".
WAN replication configuration for cache.
Adds the Split Brain Protection for this data-structure which you configure using the split-brain-protection element.
You should set the split-brain-protection-ref's value as the split brain protection's name.
Disables invalidation events for per entry but full-flush invalidation events are still enabled.
Full-flush invalidation event means that invalidation events for all entries on clear.
Name of the cache.
Fully-qualified comparator's class name to be used for the priority queue.
If nothing is provided, then queue behaves as a FIFO queue.
If this value is non-null, then Hazelcast will ignore the queue store
"memory-limit" configuration value.
True (default) if statistics gathering is enabled on the queue, false otherwise.
Maximum number of items in the queue.
Any integer between 0 and Integer.MAX_VALUE. 0 means Integer.MAX_VALUE. Default is 0.
Number of synchronous backups. For example, if 1 is set as the backup-count,
then all entries of the queue are copied to one other JVM for
fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
Number of asynchronous backups. For example, if 1 is set as the backup-count,
then all entries of the queue are copied to one other JVM for
fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
Used to purge unused or empty queues. If you define a value (time in seconds) for this element,
then your queue will be destroyed if it stays empty or unused for that time.
Lets you add listeners (listener classes) for the queue items. You can also set the attribute
include-value to true if you want the item event to contain the item values, and you can set
local to true if you want to listen to the items on the local node.
Includes the queue store factory class name and the following properties.
Binary: By default, Hazelcast stores the queue items in serialized form in memory.
Before it inserts the queue items into datastore, it deserializes them. But if you
will not reach the queue store from an external application, you might prefer that the
items be inserted in binary form. You can get rid of the de-serialization step; this
would be a performance optimization. The binary feature is disabled by default.
Memory Limit: This is the number of items after which Hazelcast will store items only to
datastore. For example, if the memory limit is 1000, then the 1001st item will be put
only to datastore. This feature is useful when you want to avoid out-of-memory conditions.
The default number for memory-limit is 1000. If you want to always use memory, you can set
it to Integer.MAX_VALUE.
Bulk Load: When the queue is initialized, items are loaded from QueueStore in bulks. Bulk
load is the size of these bulks. By default, bulk-load is 250.
Adds the Split Brain Protection for this data-structure which you configure using the split-brain-protection element.
You should set the split-brain-protection-ref's value as the split brain protection's name.
Name of the queue.
True (default) if statistics gathering is enabled on the list, false otherwise.
Maximum size of the list.
Any integer between 0 and Integer.MAX_VALUE. 0 means Integer.MAX_VALUE. Default is 0.
Number of synchronous backups. For example, if 1 is set as the backup-count,
then all entries of the list are copied to one other JVM for
fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
Number of asynchronous backups. For example, if 1 is set as the backup-count,
then all entries of the list will be copied to one other JVM for
fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
Lets you add listeners (listener classes) for the list items. You can also set the attribute
include-value to true if you want the item event to contain the item values, and you can set
local to true if you want to listen to the items on the local node.
Adds the Split Brain Protection for this data-structure which you configure using the split-brain-protection element.
You should set the split-brain-protection-ref's value as the split brain protection's name.
Name of the list.
True (default) if statistics gathering is enabled on the set, false otherwise.
Maximum size of the set.
Any integer between 0 and Integer.MAX_VALUE. 0 means Integer.MAX_VALUE. Default is 0.
Number of synchronous backups. For example, if 1 is set as the backup-count,
then all entries of the set are copied to one other JVM for
fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
Number of asynchronous backups. For example, if 1 is set as the backup-count,
then all entries of the set will be copied to one other JVM for
fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
Lets you add listeners (listener classes) for the set items. You can also set the attribute
include-value to true if you want the item event to contain the item values, and you can set
local to true if you want to listen to the items on the local node.
Adds the Split Brain Protection for this data-structure which you configure using the split-brain-protection element.
You should set the split-brain-protection-ref's value as the split brain protection's name.
Name of the set.
Hazelcast MultiMap is a specialized map where you can store multiple values under a single key.
Just like any other distributed data structure implementation in Hazelcast, MultiMap is distributed
and thread-safe. Hazelcast MultiMap is not an implementation of java.util.Map due to the difference
in method signatures. It supports most features of Hazelcast Map except for indexing, predicates and
MapLoader/MapStore.
Number of synchronous backups. For example, if 1 is set as the backup-count,
then all entries of the multimap are copied to one other JVM for
fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
Number of asynchronous backups. For example, if 1 is set as the backup-count,
then all entries of the multimap are copied to one other JVM for
fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
True (default) if statistics gathering is enabled on the multimap, false otherwise.
By default, BINARY in-memory format is used, meaning that the object is stored
in a serialized form. You can set it to false, then, the OBJECT in-memory format
is used, which is useful when the OBJECT in-memory format has a smaller memory
footprint than BINARY.
Type of the value collection : SET or LIST.
Lets you add listeners (listener classes) for the multimap entries. You can also set the attribute
include-value to true if you want the item event to contain the entry values, and you can set
local to true if you want to listen to the entries on the local node.
Adds the Split Brain Protection for this data-structure which you configure using the split-brain-protection element.
You should set the split-brain-protection-ref's value as the split brain protection's name.
Name of the multimap.
A ReplicatedMap is a map-like data structure with weak consistency
and values locally stored on every node of the cluster.
Whenever a value is written asynchronously, the new value will be internally
distributed to all existing cluster members, and eventually every node will have
the new value.
When a new node joins the cluster, the new node initially will request existing
values from older nodes and replicate them locally.
Data type used to store entries.
Possible values:
BINARY: keys and values are stored as binary data.
OBJECT (default): values are stored in their object forms.
NATIVE: keys and values are stored in native memory. Only available on Hazelcast Enterprise.
True if the replicated map is available for reads before the initial
replication is completed, false otherwise. Default is true. If false, no Exception will be
thrown when the replicated map is not yet ready, but call is blocked until
the initial replication is completed.
True (default) if statistics gathering is enabled on the replicated map, false otherwise.
Lets you add listeners (listener classes) for the replicated map entries. You can also set the attribute
include-value to true if you want the item event to contain the entry values, and you can set
local to true if you want to listen to the entries on the local node.
Adds the Split Brain Protection for this data-structure which you configure using the split-brain-protection element.
You should set the split-brain-protection-ref's value as the split brain protection's name.
Name of the replicated map.
True (default) if statistics gathering is enabled on the topic, false otherwise.
Default is `false`, meaning there is no global order guarantee.
Lets you add listeners (listener classes) for the topic messages.
Default is `false`, meaning only one dedicated thread will handle topic messages.
When multi-threading enabled (true) all threads from event thread pool can be used for message handling.
The name of the topic.
Enables or disables statistics for this reliable topic.
Collects the creation time, total number of published and received
messages for each member locally. Its default value is true.
Lets you add listeners (listener classes) for the topic messages.
Sets the read batch size.
The ReliableTopic tries to read a batch of messages from the ringbuffer.
It will get at least one, but if there are more available, then it will
try to get more to increase throughput. The maximum read batch size can
be influenced using the read batch size.
Apart from influencing the number of messages to retrieve, the
readBatchSize also determines how many messages will be processed
by the thread running the MessageListener before it returns back
to the pool to look for other MessageListeners that need to be
processed. The problem with returning to the pool and looking for new work
is that interacting with an executor is quite expensive due to contention
on the work-queue. The more work that can be done without retuning to the
pool, the smaller the overhead.
If the readBatchSize is 10 and there are 50 messages available,
10 items are retrieved and processed consecutively before the thread goes
back to the pool and helps out with the processing of other messages.
If the readBatchSize is 10 and there are 2 items available,
2 items are retrieved and processed consecutively.
If the readBatchSize is an issue because a thread will be busy
too long with processing a single MessageListener and it can't
help out other MessageListeners, increase the size of the
threadpool so the other MessageListeners don't need to wait for
a thread, but can be processed in parallel.
A policy to deal with an overloaded topic; so topic where there is no place to store new messages.
This policy can only be used in combination with the
com.hazelcast.core.HazelcastInstance#getReliableTopic(String).
The reliable topic uses a com.hazelcast.ringbuffer.Ringbuffer to
store the messages. A ringbuffer doesn't track where readers are, so
it has no concept of a slow consumers. This provides many advantages like
high performance reads, but it also gives the ability to the reader to
re-read the same message multiple times in case of an error.
A ringbuffer has a limited, fixed capacity. A fast producer may overwrite
old messages that are still being read by a slow consumer. To prevent
this, we may configure a time-to-live on the ringbuffer (see
com.hazelcast.config.RingbufferConfig#setTimeToLiveSeconds(int).
Once the time-to-live is configured, the TopicOverloadPolicy
controls how the publisher is going to deal with the situation that a
ringbuffer is full and the oldest item in the ringbuffer is not old
enough to get overwritten.
Keep in mind that this retention period (time-to-live) can keep messages
from being overwritten, even though all readers might have already completed reading.
Its default value is BLOCK. Available values are as follows:
- DISCARD_OLDEST:
Using this policy, a message that has not expired can be overwritten.
No matter the retention period set, the overwrite will just overwrite
the item.
This can be a problem for slow consumers because they were promised a
certain time window to process messages. But it will benefit producers
and fast consumers since they are able to continue. This policy sacrifices
the slow producer in favor of fast producers/consumers.
- DISCARD_NEWEST:
Message that was to be published is discarded.
- BLOCK:
The caller will wait until there is space in the Ringbuffer.
- ERROR:
The publish call fails immediately.
The name of the reliable topic.
Number of items in the ringbuffer. If no time-to-live-seconds is set, the size will always
be equal to capacity after the head completed the first loop around the ring. This is
because no items are getting expired. The default value is 10000.
Sets the time to live in seconds which is the maximum number of seconds
for each item to stay in the ringbuffer before being removed.
Entries that are older than time-to-liveSeconds are removed from the
ringbuffer on the next ringbuffer operation (read or write).
Time to live can be disabled by setting time-to-liveSeconds to 0.
It means that items won't get removed because they expire. They may only
be overwritten.
When time-to-liveSeconds is disabled and after the tail does a full
loop in the ring, the ringbuffer size will always be equal to the capacity.
The time-to-liveSeconds can be any integer between 0 and Integer#MAX_VALUE.
0 means infinite. The default is 0.
Number of synchronous backups. For example, if 1 is set as the backup-count,
then the items in the ringbuffer are copied to one other JVM for
fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
Number of asynchronous backups. For example, if 1 is set as the backup-count,
then the items in the ringbuffer are copied to one other JVM for
fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
Sets the in-memory format.
Setting the in-memory format controls the format of the stored item in the
ringbuffer:
- OBJECT: the item is stored in deserialized format (a regular object)
- BINARY (default): the item is stored in serialized format (a binary blob)
The object in-memory format is useful when:
- the object stored in object format has a smaller footprint than in
binary format
- if there are readers using a filter. Since for every filter
invocation, the object needs to be available in object format.
Includes the ring buffer store factory class name. The store format is the same as the
in-memory-format for the ringbuffer.
Adds the Split Brain Protection for this data-structure which you configure using the split-brain-protection element.
You should set the split-brain-protection-ref's value as the split brain protection's name.
The name of the ringbuffer. Required.
While recovering from split-brain (network partitioning), data structure entries in the small cluster
merge into the bigger cluster based on the policy set here. When an entry merges into the cluster,
an entry with the same key (or value) might already exist in the cluster.
The merge policy resolves these conflicts with different out-of-the-box or custom strategies.
The out-of-the-box merge polices can be references by their simple class name.
For custom merge policies you have to provide a fully qualified class name.
The out-of-the-box policies are:
DiscardMergePolicy: the entry from the smaller cluster will be discarded.
HigherHitsMergePolicy: the entry with the higher number of hits wins.
LatestAccessMergePolicy: the entry with the latest access wins.
LatestUpdateMergePolicy: the entry with the latest update wins.
PassThroughMergePolicy: the entry from the smaller cluster wins.
PutIfAbsentMergePolicy: the entry from the smaller cluster wins if it doesn't exist in the cluster.
The default policy is: PutIfAbsentMergePolicy
Overrides the public address of a node. By default, a node selects its socket address
as its public address. But behind a network address translation (NAT), two endpoints (nodes)
may not be able to see/access each other. If both nodes set their public addresses to their
defined addresses on NAT, then they can communicate with each other. In this case, their
public addresses are not an address of a local network interface but a virtual address defined by NAT.
This is optional to set and useful when you have a private cloud.
The ports which Hazelcast will use to communicate between cluster members. Its default value is 5701.
It has the following attributes.
port-count: The default value is 100, meaning that Hazelcast will try to bind 100 ports.
If you set the value of port as 5701, as members join the cluster, Hazelcast tries to find
ports between 5701 and 5801. You can change the port count in cases like having large
instances on a single machine or you are willing to have only a few ports assigned.
auto-increment: Default value is true. If port is set to 5701, Hazelcast will try to find free
ports between 5701 and 5801. Normally, you will not need to change this value, but it comes
in handy when needed. You may also want to choose to use only one port. In that case, you can
disable the auto-increment feature of port by setting its value as false.
When you shutdown a cluster member, the server socket port will be in the TIME_WAIT
state for the next couple of minutes. If you start the member right after shutting it down,
you may not be able to bind it to the same port because it is in the TIME_WAIT state. If you
set reuse-address to true, the TIME_WAIT state is ignored and you can bind the member to the
same port again. Default value is false.
By default, Hazelcast lets the system pick up an ephemeral port during socket bind operation.
But security policies/firewalls may require to restrict outbound ports to be used by
Hazelcast-enabled applications. To fulfill this requirement, you can configure Hazelcast to use
only defined outbound ports.
outbound-ports has the ports attribute to allow you to define outbound ports.
SSL configuration with com.hazelcast.nio.ssl.SSLContextFactory used as the factory type.
encryption algorithm such as
DES/ECB/PKCS5Padding,
PBEWithMD5AndDES,
AES/CBC/PKCS5Padding,
Blowfish,
DESede
IMPORTANT
This configuration is not intended to provide addresses of other cluster members with
which the hazelcast instance will form a cluster. This is an SPI for advanced use in
cases where the DefaultAddressPicker does not pick suitable addresses to bind to
and publish to other cluster members. For instance, this could allow easier
deployment in some cases when running on Docker, AWS or other cloud environments.
That said, if you are just starting with Hazelcast, you will probably want to
set the member addresses by using the tcp-ip or multicast configuration
or adding a discovery strategy.
Member address provider allows to plug in own strategy to customize:
1. What address Hazelcast will bind to
2. What address Hazelcast will advertise to other members on which they can bind to
In most environments you don't need to customize this and the default strategy will work just
fine. However in some cloud environments the default strategy does not make the right choice and
the member address provider delegates the process of address picking to external code.
IP address of the required member. Cluster will form only if the member with this IP
address is found.
IP address(es) of one or more well known members. Once members are connected to these
well known ones, all member addresses will be communicated with each other.
Comma separated IP addresses of one or more well known members.
Specifies whether the TCP/IP discovery is enabled or not. Default value is false.
The maximum amount of time Hazelcast is going to try to connect to a well known member
before giving up. Setting it to a too low value could mean that a member is not able
to connect to a cluster. Setting it to a too high value means that member startup could
slow down because of longer timeouts (e.g. when a well known member is not up). Increasing
this value is recommended if you have many IPs listed and the members cannot properly
build up the cluster. Its default value is 5.
The name of the class implementing the com.hazelcast.spi.MemberAddressProvider interface
Specifies whether the member address provider SPI is enabled or not. Values can be true or false.
The multicast group IP address. Specify it when you want to create clusters within the
same network. Values can be between 224.0.0.0 and 239.255.255.255. Default value is 224.2.2.3.
The multicast socket port through which the Hazelcast member listens and sends discovery messages.
Default value is 54327.
Only when the nodes are starting up, this timeout (in seconds) specifies the period during
which a node waits for a multicast response from another node. For example, if you set it
to 60 seconds, each node will wait for 60 seconds until a leader node is selected.
Its default value is 2 seconds.
Time-to-live value for multicast packets sent out to control the scope of multicasts.
Includes IP addresses of trusted members. When a node wants to join to the cluster,
its join request will be rejected if it is not a trusted member. You can give an IP
addresses range using the wildcard (*) on the last digit of the IP address
(e.g. 192.168.1.* or 192.168.1.100-110).
Specifies whether the multicast discovery is enabled or not. Values can be true or false.
Allows explicitly specifying the loopbackMode on multicast sockets.
It enables or disables local loopback of multicast datagrams.
The option is used by the platform's networking code as a "hint" for setting whether
multicast data will be looped back to the local socket.
As it's a hint, the underlying platform code doesn't need to respect the setting.
Specifies whether the EC2 discovery is enabled or not. Value can be true or false.
The maximum amount of time Hazelcast is going to try to connect to a well known member
before giving up. Please check if the specific discovery strategy supports this property.
Specifies whether the auto-detection discovery is enabled or not. Values can be true or false.
The `join` configuration element is used to enable the Hazelcast instances to form a cluster,
i.e. to join the members. Three ways can be used to join the members: discovery by TCP/IP, by
multicast, and by discovery on AWS (EC2 auto-discovery).
You can specify which network interfaces that Hazelcast should use. Servers mostly have more
than one network interface, so you may want to list the valid IPs. Range characters
('\*' and '-') can be used for simplicity. For instance, 10.3.10.\* refers to IPs between
10.3.10.0 and 10.3.10.255. Interface 10.3.10.4-18 refers to IPs between 10.3.10.4 and
10.3.10.18 (4 and 18 included). If network interface configuration is enabled (it is disabled
by default) and if Hazelcast cannot find an matching interface, then it will print a message
on the console and will not start on that node.
True to enable these interfaces, false to disable.
True (default) if statistics gathering is enabled on the executor task, false otherwise.
The number of executor threads per member for the executor.
Queue capacity of the executor task. 0 means Integer.MAX_VALUE.
Adds the Split Brain Protection for this data-structure which you configure using the split-brain-protection element.
You should set the split-brain-protection-ref's value as the split brain protection's name.
Name of the executor task.
True (default) if statistics gathering is enabled on the executor task, false otherwise.
The number of executor threads per member for the executor.
The durability of the executor
Capacity of the executor task per partition.
Adds the Split Brain Protection for this data-structure which you configure using the split-brain-protection element.
You should set the split-brain-protection-ref's value as the split brain protection's name.
Name of the durable executor.
True (default) if statistics gathering is enabled on the executor task, false otherwise.
The number of executor threads per member for the executor.
The durability of the scheduled executor.
The maximum number of tasks that a scheduler can have at any given point
in time as per capacity-policy.
Once the capacity is reached, new tasks will be rejected.
Capacity is ignored upon migrations to prevent any undesirable data-loss.
The active policy for the capacity setting
capacity-policy has these valid values:
PER_NODE: Maximum number of tasks in each Hazelcast instance.
This is the default policy.
PER_PARTITION: Maximum number of tasks within each partition. Storage size
depends on the partition count in a Hazelcast instance.
This attribute should not be used often.
Avoid using this attribute with a small cluster: if the cluster is small it will
be hosting more partitions, and therefore tasks, than that of a larger
cluster.
Adds the Split Brain Protection for this data-structure which you configure using the split-brain-protection element.
You should set the split-brain-protection-ref's value as the split brain protection's name.
Name of the scheduled executor.
Number of synchronous backups. For example, if 1 is set as the backup-count,
then the cardinality estimation will be copied to one other JVM for
fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
Number of asynchronous backups. For example, if 1 is set as the async-backup-count,
then cardinality estimation will be copied to one other JVM (asynchronously) for
fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
Adds the Split Brain Protection for this data-structure which you configure using the split-brain-protection element.
You should set the split-brain-protection-ref's value as the split brain protection's name.
While recovering from split-brain (network partitioning), CardinalityEstimator in the small cluster
merge into the bigger cluster based on the policy set here. When an estimator merges into the cluster,
an estimator with the same name might already exist in the cluster.
The merge policy resolves these conflicts with different out-of-the-box strategies.
The out-of-the-box merge polices can be references by their simple class name.
The out-of-the-box policies are:
DiscardMergePolicy: the estimator from the smaller cluster will be discarded.
HyperLogLogMergePolicy: the estimator will merge with the existing one, using the algorithmic merge for HyperLogLog.
PassThroughMergePolicy: the estimator from the smaller cluster wins.
PutIfAbsentMergePolicy: the estimator from the smaller cluster wins if it doesn't exist in the cluster.
The default policy is: HyperLogLogMergePolicy
Name of the cardinality estimator.
Enterprise only. Hazelcast allows you to encrypt the entire socket level communication among
all Hazelcast members. Encryption is based on Java Cryptography Architecture. In symmetric
encryption, each node uses the same key, so the key is shared.
Encryption algorithm such as DES/ECB/PKCS5Padding, PBEWithMD5AndDES, Blowfish,
or DESede.
Salt value to use when generating the secret key.
Pass phrase to use when generating the secret key.
Iteration count to use when generating the secret key.
True to enable symmetric encryption, false to disable.
ICMP can be used in addition to the other detectors. It operates at layer 3 detects network
and hardware issues more quickly
Timeout in Milliseconds before declaring a failed ping
Maximum number of times the IP Datagram (ping) can be forwarded, in most cases
all Hazelcast cluster members would be within one network switch/router therefore
default of 0 is usually sufficient
Run ICMP detection in parallel with the Heartbeat failure detector
Cluster Member will fail to start if it is unable to action an ICMP ping command when ICMP is enabled.
Failure is usually due to OS level restrictions.
Maximum number of consecutive failed attempts before declaring a member suspect
Time in milliseconds between each ICMP ping
Enables ICMP Pings to detect and suspect dead members
The name of the class implementing MapLoader and/or MapStore.
The number of seconds to delay the store writes. Default value is 0.
The number of operations to be included in each batch processing round. Default value is 1.
Setting this is meaningful if you are using write behind in MapStore. When write-coalescing is true,
only the latest store operation on a key in the write-delay-seconds time-window will be
reflected to MapStore. Default value is true.
True to enable this map-store, false to disable.
Sets the initial load mode.
LAZY: default load mode, where load is asynchronous.
EAGER: load is blocked till all partitions are loaded.
True to enable value caching, false to disable.
The predicate to filter events which will be applied to the QueryCache.
Lets you add listeners (listener classes) for the query cache entries.
Data type used to store entries.
Possible values:
BINARY (default): keys and values are stored as binary data.
OBJECT: values are stored in their object forms.
NATIVE: keys and values are stored in native memory. Only available on Hazelcast Enterprise.
True to enable initial population of the query cache, false otherwise.
True to enable coalescing of the query cache, false otherwise.
The minimum number of seconds that an event waits in the node buffer.
The batch size used to determine the number of events sent
in a batch to the query cache.
The maximum number of events which can be stored in a partition buffer.
Configuration object for the built-in WAN publisher (available in
Hazelcast Enterprise). The publisher sends events to another Hazelcast
cluster in batches, sending when either when enough events are enqueued
or enqueued events have waited for enough time.
The endpoint can be a different cluster defined by static IP's or
discovered using a cloud discovery mechanism.
Configuration object for a custom WAN publisher. A single publisher defines how
WAN events are sent to a specific endpoint.
The endpoint can be some other external system which is
not a Hazelcast cluster (e.g. JMS queue).
Name for your WAN replication configuration.
Sets the cluster name used as an endpoint cluster name for authentication
on the target endpoint.
If there is no separate publisher ID property defined, this cluster name
will also be used as a WAN publisher ID. This ID is then used for
identifying the publisher in a WanReplicationConfig.
Sets if key-based coalescing is configured for this WAN publisher.
When enabled, only the latest WanReplicationEvent
of a key is sent to target.
Defines the initial state in which a WAN publisher is started.
- REPLICATING (default):
State where both enqueuing new events is allowed, enqueued events are replicated to the target cluster
and WAN sync is enabled.
- PAUSED:
State where new events are enqueued but they are not dequeued. Some events which have been dequeued before
the state was switched may still be replicated to the target cluster but further events will not be
replicated. WAN sync is enabled.
- STOPPED:
State where neither new events are enqueued nor dequeued. As with the PAUSED state, some events might
still be replicated after the publisher has switched to this state. WAN sync is enabled.
Sets the capacity of the primary and backup queue for WAN replication events.
One hazelcast instance can have up to 2*queueCapacity events since
we keep up to queueCapacity primary events (events with keys for
which the instance is the owner) and queueCapacity backup events
(events with keys for which the instance is the backup).
Events for IMap and ICache count against this limit collectively.
When the queue capacity is reached, backup events are dropped while normal
replication events behave as determined by the queue-full-behavior.
Sets the maximum batch size that can be sent to target cluster.
Sets the maximum amount of time in milliseconds to wait before sending a
batch of events to target cluster, if batch-size of events
have not arrived within this duration.
Sets the duration in milliseconds for the waiting time before retrying to
send the events to target cluster again in case of acknowledgement
is not arrived.
Sets the configured behaviour of this WAN publisher when the WAN queue is
full.
Sets the strategy for when the target cluster should acknowledge that
a WAN event batch has been processed.
Sets the period in seconds in which WAN tries to discover new target
endpoints and reestablish connections to failed endpoints.
Returns the maximum number of endpoints that WAN will connect to when
using a discovery mechanism to define endpoints.
This property has no effect when static endpoint addresses are defined
using target-endpoints.
Sets the maximum number of WAN event batches being sent to the target
cluster concurrently.
Setting this property to anything less than 2 will only allow a
single batch of events to be sent to each target endpoint and will
maintain causality of events for a single partition.
Setting this property to 2 or higher will allow multiple batches
of WAN events to be sent to each target endpoint. Since this allows
reordering or batches due to network conditions, causality and ordering
of events for a single partition is lost and batches for a single
partition are now sent randomly to any available target endpoint.
This, however, does present faster WAN replication for certain scenarios
such as replicating immutable, independent map entries which are only
added once and where ordering of when these entries are added is not
necessary.
Keep in mind that if you set this property to a value which is less than
the target endpoint count, you will lose performance as not all target
endpoints will be used at any point in time to process WAN event batches.
So, for instance, if you have a target cluster with 3 members (target
endpoints) and you want to use this property, it makes sense to set it
to a value higher than 3. Otherwise, you can simply disable it
by setting it to less than 2 in which case WAN will use the
default replication strategy and adapt to the target endpoint count
while maintaining causality.
Sets whether the WAN connection manager should connect to the
endpoint on the private address returned by the discovery SPI.
By default this property is false which means the WAN connection
manager will always use the public address.
Sets the minimum duration in nanoseconds that the WAN replication thread
will be parked if there are no events to replicate.
Sets the maximum duration in nanoseconds that the WAN replication thread
will be parked if there are no events to replicate.
Sets the publisher ID used for identifying the publisher in a
WanReplicationConfig.
If there is no publisher ID defined (it is empty), the cluster name will
be used as a publisher ID.
Comma separated list of target cluster members,
e.g. 127.0.0.1:5701, 127.0.0.1:5702.
Reference to the name of a WAN endpoint config or WAN server socket endpoint config.
The network settings from the referenced endpoint configuration will setup the network
configuration of connections to the target WAN cluster members.
Sets the publisher ID used for identifying the publisher in a
WanReplicationConfig.
If there is no publisher ID defined (it is empty), the cluster name will
be used as a publisher ID.
Fully qualified class name of WAN Replication implementation WanPublisher.
Sets the strategy for checking consistency of data between source and
target cluster. Any inconsistency will not be reconciled, it will be
merely reported via the usual mechanisms (e.g. statistics, diagnostics).
The user must initiate WAN sync to reconcile there differences. For the
check procedure to work properly, the target cluster should support the
chosen strategy.
Default value is NONE, which means the check is disabled.
Config for processing WAN events received from a target cluster.
You can configure certain behaviour when processing incoming WAN events
or even configure your own implementation for a WAN consumer. A custom
WAN consumer allows you to define custom processing logic and is usually
used in combination with a custom WAN publisher.
A custom consumer is optional and you may simply omit defining it which
will cause the default processing logic to be used.
Sets the fully qualified class name of the class implementing
a custom WAN consumer (WanConsumer).
If you don't define a class name, the default processing logic for
incoming WAN events will be used.
Properties for the custom WAN consumer. These properties are
accessible when initalizing the WAN consumer.
When true, an incoming event over WAN replication can be persisted to a
database for example, otherwise it will not be persisted. Default value
is false.
Full factory classname.
True to enable this configuration element, false to disable.
When you enable partition grouping, Hazelcast presents three choices for you to configure
partition groups.
HOST_AWARE: You can group nodes automatically using the IP addresses of nodes, so nodes
sharing the same network interface will be grouped together. All members on the same host
(IP address or domain name) will be a single partition group.
CUSTOM: You can do custom grouping using Hazelcast's interface matching configuration.
This way, you can add different and multiple interfaces to a group.
PER_MEMBER: You can give every member its own group. Each member is a group of its own
and primary and backup partitions are distributed randomly (not on the same physical member).
Includes allowed IP addresses for Management Center connections.
More preciselly, the element configures addresses from which clients are allowed to run cluster
management tasks over the Hazelcast client protocol.
You can give an IP addresses range using the wildcard (*) on the last digit of the IP address
(e.g. 192.168.1.* or 192.168.1.100-110).
True to allow scripting on the member, false to disallow.
Block or allow actions, submitted as tasks in an Executor from clients and have no permission mappings.
true: Blocks all actions that have no permission mapping
false: Allows all actions that have no permission mapping
Endpoint address of the principal. Wildcards(*) can be used.
Name of the principal. Wildcards(*) can be used.
Name of the permission. Wildcards(*) can be used.
Optional name of the permission. Simple wildcard (*) or prefixes (prefix.*) can be used.
Permission actions that are permitted on Hazelcast instance objects.
One of the following: membership-listener, instance-listener, migration-listener or
partition-lost-listener.
Data type used to store entries.
Possible values:
BINARY (default): keys and values are stored as binary data.
OBJECT: values are stored in their object forms.
NATIVE: keys and values are stored in native memory. Only available on Hazelcast Enterprise.
Defines if the Near Cache keys should be serialized or not.
Keys should be serialized if they are mutable and need to be cloned via serialization.
NOTE: It's not supported to disable key serialization with in-memory-format NATIVE.
This setting will have no effect in that case.
Default value is false.
True to evict the cached entries if the entries are changed (updated or removed).
Default value is true.
Maximum number of seconds for each entry to stay in the Near Cache. Entries that are
older than time-to-live-seconds will get automatically evicted from the Near Cache.
Any integer between 0 and Integer.MAX_VALUE. 0 means infinite. Default is 0.
Maximum number of seconds each entry can stay in the Near Cache as untouched (not-read).
Entries that are not read (touched) more than max-idle-seconds value will get removed
from the Near Cache.
Any integer between 0 and Integer.MAX_VALUE. 0 means Integer.MAX_VALUE. Default is 0.
True to cache local entries, which belong to the member itself.
This is useful when in-memory-format for Near Cache is different than the map's one.
Default value is false.
The version of the portable serialization. Portable version is used to differentiate two
same classes that have changes on it like adding/removing field or changing a type of a field.
True to use native byte order of the underlying platform, false otherwise. Default value is false.
Defines the byte order that the serialization will use.
True to enable compression if default Java serialization is used, false otherwise.
Default value is false.
True to enable shared object if default Java serialization is used, false otherwise.
Default value is false.
True to allow the usage of unsafe, false otherwise.
Default value is false.
True to allow override of default serializers.
Default value is false.
Custom classes implementing com.hazelcast.nio.serialization.DataSerializableFactory to be
registered. These can be used to speed up serialization/deserialization of objects.
PortableFactory class to be registered.
Global serializer class to be registered if no other serializer is applicable.
Defines the class name and the type class of the serializer implementation.
If true (default), serialization system will check class definitions error at start and throw a
Serialization Exception with error definition.
Basic protection against untrusted deserialization based on class/package blacklisting and whitelisting.
The name of the class that will be serialized.
The type of the class that will be serialized.
Java Serializable and Externalizable is prior to global serializer by default. If set true
the Java serialization step assumed to be handled by the global serializer.
Blacklisted classes and packages, which are not allowed to be deserialized.
Whitelisted classes and packages, which are allowed to be deserialized. If the list is empty
(no class or package name provided) then all classes are allowed.
Disables including default list entries (hardcoded in Hazelcast source code).
Name of a class to be included in the list.
Name of a package to be included in the list.
Class name prefix to be included in the list.
Configuration for persistent memory (e.g. Intel Optane) devices.
List of directories where the persistent memory
is mounted to. Requires the mode attribute of persistent-memory
to be MOUNTED (default).
If the specified directories are not unique either in the directories
themselves or in the NUMA nodes specified for them,
the configuration is treated as invalid. Setting the NUMA
node on the subset of the configured directories while leaving
not set on others also makes the configuration invalid.
Sets if using persistent memory as Hazelcast native memory is enabled.
Sets the operational mode of the persistent memory configured
on the machine.
The persistent memory is mounted into the file system (also known as FS DAX mode).
The persistent memory is onlined as system memory (also known as KMEM DAX mode).
The directory where persistent memory is mounted to.
If the specified directory id not unique either in the
directory itself or in the NUMA node specified, the
configuration will be treated as invalid. Setting the NUMA
node on the subset of the configured directories while leaving
not set on others also results in invalid configuration.
The NUMA node that the persistent memory mounted
to the given directory is attached to.
NUMA nodes have to be unique across the entire
persistent memory configuration, otherwise the
configuration will be treated as invalid. Similarly,
setting the NUMA node on the subset of the configured
directories while leaving not set on others also
results in invalid configuration.
A full list of available properties can be found at
http://docs.hazelcast.org/docs/latest/manual/html-single/index.html#system-properties
Sets the merge policy sent to the WAN replication target to merge
replicated entries with existing target entries.
The default merge policy is com.hazelcast.spi.merge.PassThroughMergePolicy.
Sets the list of class names implementing the CacheWanEventFilter or
MapWanEventFilter for filtering outbound WAN replication events.
When enabled, an incoming event to a member is forwarded to the target cluster of that member.
Name of the wan-replication configuration. IMap or ICache instance uses this wan-replication config.
The minimum number of members required in a cluster for the cluster to remain in an
operational state. If the number of members is below the defined minimum at any time,
the operations are rejected and the rejected operations throw a SplitBrainProtectionException to
their callers.
You can register split brain protection listeners to be notified about split brain protection
results. Split brain protection listeners are local to the member that they are registered,
so they receive only events occurred on that local member.
Determines split based protection based on the number of currently live cluster members.
The minimum number of members required in a cluster for the cluster to remain in an
operational state is configured separately in <minimum-cluster-size> element.
If the number of members is below the defined minimum at any time,
the operations are rejected and the rejected operations throw a SplitBrainProtectionException to
their callers.
A probabilistic split brain protection function based on Phi Accrual failure detector. See
com.hazelcast.internal.cluster.fd.PhiAccrualClusterFailureDetector for implementation
details. Configuration:
- acceptable-heartbeat-pause-millis: duration in milliseconds corresponding to number
of potentially lost/delayed heartbeats that will be accepted before considering it to be an anomaly.
This margin is important to be able to survive sudden, occasional, pauses in heartbeat arrivals,
due to for example garbage collection or network drops.
- suspicion-threshold: threshold for suspicion level. A low threshold is prone to generate
many wrong suspicions but ensures a quick detection in the event of a real crash. Conversely, a high
threshold generates fewer mistakes but needs more time to detect actual crashes.
- max-sample-size: number of samples to use for calculation of mean and standard
deviation of inter-arrival times.
- heartbeat-interval-millis: bootstrap the stats with heartbeats that corresponds to
this duration in milliseconds, with a rather high standard deviation (since environment is unknown
in the beginning)
- min-std-deviation-millis: minimum standard deviation (in milliseconds) to use for the normal
distribution used when calculating phi. Too low standard deviation might result in too much
sensitivity for sudden, but normal, deviations in heartbeat inter arrival times.
A split brain protection function that keeps track of the last heartbeat timestamp per each member.
For a member to be considered live (for the purpose to conclude whether the minimum cluster size property is satisfied)
a heartbeat must have been received at most heartbeat-tolerance milliseconds before
current time.
True to set the node as a lite member, false otherwise.
Controls caching of user classes loaded from remote members.
OFF: Never caches loaded classes. This is suitable for loading runnables, callables,
entry processors, etc.
ETERNAL: Cache indefinitely. This is suitable when you load long-living objects,
such as domain objects stored in a map.
Controls how to react on receiving a classloading request from a remote member
OFF: Never serve classes to other members. This member will never server classes to remote
members.
LOCAL_CLASSES_ONLY: Serve classes from local classpath only. Classes loaded from other members
will be used locally, but they won't be served to other members.
LOCAL_AND_CACHED_CLASSES: Server classes loaded from both local classpath and from other members.
Filter to constraint members to be used for classloading request when a class
is not available locally.
Command separated list of prefixes of classes which will be loaded remotely.
Use this to enable loading of explicitly selected user classes only and
disable remote loading for all other classes. This gives you a fine-grained control
over classloading.
Filter to constraint members to be used for classloading request when a class
is not available locally.
Filter format: HAS_ATTRIBUTE:foo this will send classloading requests
only to members which has a member attribute foo set. Value is ignored,
it can be any type. A present of the attribute is sufficient.
This facility allows to have a control on classloading. You can e.g. start Hazelcast lite
members dedicated for class-serving.
Setting the filter to null will allow to load classes from all members.
True to enable User Code Deployment on this member, false otherwise.
The path of the KeyStore file.
The type of the KeyStore (PKCS12, JCEKS, etc.).
The password to access the KeyStore.
The alias for the current encryption key entry (optional).
The polling interval (in seconds) for checking for changes in the KeyStore.
Java KeyStore Secure Store configuration.
The address of the Vault server.
The Vault secret path.
The Vault access token.
SSL/TLS configuration for HTTPS connections.
The polling interval (in seconds) for checking for changes in Vault.
HashiCorp Vault Secure Store configuration.
Configuration for persistence (symmetric) encryption at rest. Encryption is based
on Java Cryptography Architecture.
Encryption algorithm such as AES/CBC/PKCS5Padding, DES/ECB/PKCS5Padding, Blowfish,
or DESede.
Salt value to use when generating the secret key.
The key size in bits used when generating encryption keys (optional).
The default value of 0 implies falling back to the cipher-specific
default key size.
The Secure Store configuration.
True to enable symmetric encryption, false to disable.
DEPRECATED, use 'persistence' instead.
Note: If either, but not both, hot-restart-persistence or
persistence is enabled, Hazelcast will use the configuration of the enabled element. If both are
enabled, Hazelcast will use the persistence configuration.
hot-restart-persistence element will be removed in a future release.
Base directory for all hot-restart data. Can be an absolute or relative path to the node startup
directory.
Base directory for hot backups. Each new backup will be created in a separate directory inside this one.
Can be an absolute or relative path to the node startup directory.
Level of parallelism in Hot Restart Persistence. There will be this many IO threads,
each writing in parallel to its own files. During the Hot Restart procedure, this many
IO threads will be reading the files and this many Rebuilder threads will be rebuilding
the HR metadata.
Validation timeout for the Hot Restart procedure. Includes the time to validate
cluster members expected to join and partition table of the whole cluster.
DEPRECATED. Please leave it to default.
Data load timeout for Hot Restart procedure. All members in the cluster should
complete restoring their local data before this timeout.
Specifies the policy that will be respected during hot restart cluster start. Valid values are :
FULL_RECOVERY_ONLY : Starts the cluster only when all expected nodes are present and correct.
Otherwise, it fails.
PARTIAL_RECOVERY_MOST_RECENT : Starts the cluster with the members which have most up-to-date
partition table and successfully restored their data. All other members will leave the cluster and
force-start themselves. If no member restores its data successfully, cluster start fails.
PARTIAL_RECOVERY_MOST_COMPLETE : Starts the cluster with the largest group of members which have the
same partition table version and successfully restored their data. All other members will leave the
cluster and force-start themselves. If no member restores its data successfully, cluster start fails.
Sets whether or not automatic removal of stale Hot Restart data is enabled.
When a member terminates or crashes when cluster state is ACTIVE, remaining members
redistributes data among themselves and data persisted on terminated member's storage becomes
stale. That terminated member cannot rejoin the cluster without removing Hot Restart data.
When auto-removal of stale Hot Restart data is enabled, while restarting that member,
Hot Restart data is automatically removed and it joins the cluster as a completely new member.
Otherwise, Hot Restart data should be removed manually.
Specifies parameters for encryption of Hot Restart data. This includes the encryption algorithm
to be used (such as AES, DESede etc.) and the Secure Store configuration for retrieving the
encryption keys.
True to enable Hot Restart Persistence, false otherwise.
Successor of hot-restart-persistence.
Note: If either, but not both, hot-restart-persistence or
persistence is enabled, Hazelcast will use the configuration of the enabled element. If both are
enabled, Hazelcast will use the persistence configuration.
hot-restart-persistence element will be removed in a future release.
Base directory for all persistence data. Can be an absolute or relative path to the node startup
directory.
Base directory for persistence backups. Each new backup will be created in a separate directory inside this one.
Can be an absolute or relative path to the node startup directory.
DEPRECATED. Please leave it to default.
Level of parallelism in Persistence. There will be this many IO threads,
each writing in parallel to its own files. During the restart procedure, this many
IO threads will be reading the files and this many Rebuilder threads will be rebuilding
the Persistence metadata.
Validation timeout for the restart procedure. Includes the time to validate
cluster members expected to join and partition table of the whole cluster.
DEPRECATED. Please leave it to default.
Data load timeout for the persistence procedure. All members in the cluster should
complete restoring their local data before this timeout.
Specifies the policy that will be respected during cluster restart. Valid values are :
FULL_RECOVERY_ONLY : Starts the cluster only when all expected nodes are present and correct.
Otherwise, it fails.
PARTIAL_RECOVERY_MOST_RECENT : Starts the cluster with the members which have most up-to-date
partition table and successfully restored their data. All other members will leave the cluster and
force-start themselves. If no member restores its data successfully, cluster start fails.
PARTIAL_RECOVERY_MOST_COMPLETE : Starts the cluster with the largest group of members which have the
same partition table version and successfully restored their data. All other members will leave the
cluster and force-start themselves. If no member restores its data successfully, cluster start fails.
Sets whether or not automatic removal of stale Persistence data is enabled.
When a member terminates or crashes when cluster state is ACTIVE, remaining members
redistributes data among themselves and data persisted on terminated member's storage becomes
stale. That terminated member cannot rejoin the cluster without removing Persistence data.
When auto-removal of stale Persistence data is enabled, while restarting that member,
Persistence data is automatically removed and it joins the cluster as a completely new member.
Otherwise, Persistence data should be removed manually.
Specifies parameters for encryption of Persistence data. This includes the encryption algorithm
to be used (such as AES, DESede etc.) and the Secure Store configuration for retrieving the
encryption keys.
Time (in seconds) to wait before triggering automatic partition rebalancing
after a member leaves the cluster unexpectedly. Unexpectedly in this context
means that a member leaves the cluster by means other than graceful shutdown:
programmatic termination (eg LifecycleService.terminate()), a
process crash or network partition.
Default is 0, which means rebalancing is triggered immediately.
Setting this to a higher value will allow some time for members that are gone
to rejoin the cluster. The benefit is that partition rebalancing in this
case will be avoided, saving the burden of migrating partition data over
the network.
Do not use this option if your cluster also stores in-memory data. This option
stops the cluster from migrating in-memory data. As a result any data that is
not persisted will be lost if the member restarts within the configured delay,
including backups.
While members are gone, operations on partitions for which the owner is missing
may fail immediately or will be retried until the member rejoins or operation
timeout is exceeded.
Notice that this delay only applies when cluster members leave the cluster;
when the cluster is being scaled up and members are being added, partition
rebalancing will be triggered immediately (subject to limitations imposed
by the current cluster state).
True to enable Persistence, false otherwise.
The period between two replications of CRDT states in milliseconds.
A lower value will increase the speed at which changes are disseminated
to other cluster members at the expense of burst-like behaviour - less
updates will be batched together in one replication message and one
update to a CRDT may cause a sudden burst of replication messages in a
short time interval.
The value must be a positive non-null integer.
The maximum number of target members that we replicate the CRDT states
to in one period. A higher count will lead to states being disseminated
more rapidly at the expense of burst-like behaviour - one update to a
CRDT will lead to a sudden burst in the number of replication messages
in a short time interval.
DEPRECATED, use 'data-persistence' instead.
Note: If either, but not both, data-persistence or hot-restart is enabled,
Hazelcast will use the configuration of the enabled element. If both are
enabled, Hazelcast will use the data-persistence configuration.
hot-restart element will be removed in a future release.
If set to true, when each update operation on this structure completes,
it is guaranteed that it has already been persisted.
True if Hot Restart Persistence is enabled, false otherwise. Only available on Hazelcast Enterprise.
Successor to hot-restart.
Note: If either, but not both, data-persistence or hot-restart is enabled,
Hazelcast will use the configuration of the enabled element. If both are
enabled, Hazelcast will use the data-persistence configuration.
hot-restart element will be removed in a future release.
If set to true, when each update operation on this structure completes,
it is guaranteed that it has already been persisted.
True if Data Persistence is enabled, false otherwise. Only available on Hazelcast Enterprise.
Configuration for an event journal. The event journal keeps events related
to a specific partition and data structure. For instance, it could keep
map or cache add, update, remove, merge events along with the key, old value,
new value and so on.
This configuration is not tied to a specific data structure and can be reused.
The capacity of the event journal. The capacity is the total number of items that the event journal
can hold at any moment. The actual number of items contained in the journal can be lower.
Its default value is 10000. The capacity is shared equally between all partitions.
This is done by assigning each partition getCapacity() / partitionCount
available slots in the event journal. Because of this, the effective total
capacity may be somewhat lower and you must take into account that the
configured capacity is at least greater than the partition count.
Maximum number of seconds for each entry to stay in the event journal.
Entries that are older than <time-to-live-seconds> are evicted from the journal.
Any integer between 0 and Integer.MAX_VALUE. 0 means infinite. Default is 0.
True if the event journal is enabled, false otherwise.
Configuration for a merkle tree.
The merkle tree is a data structure used for efficient comparison of the
difference in the contents of large data structures. The precision of
such a comparison mechanism is defined by the depth of the merkle tree.
A larger depth means that a data synchronization mechanism will be able
to pinpoint a smaller subset of the data structure contents in which a
change occurred. This causes the synchronization mechanism to be more
efficient. On the other hand, a larger tree depth means the merkle tree
will consume more memory.
A smaller depth means the data synchronization mechanism will have to
transfer larger chunks of the data structure in which a possible change
happened. On the other hand, a shallower tree consumes less memory.
The depth must be between 2 and 27 (exclusive).
As the comparison mechanism is iterative, a larger depth will also prolong
the duration of the comparison mechanism. Care must be taken to not have
large tree depths if the latency of the comparison operation is high.
The default depth is 10.
See https://en.wikipedia.org/wiki/Merkle_tree.
The depth of the merkle tree.
A larger depth means that a data synchronization mechanism will be able
to pinpoint a smaller subset of the data structure contents in which a
change occurred. This causes the synchronization mechanism to be more
efficient. On the other hand, a larger tree depth means the merkle tree
will consume more memory.
A smaller depth means the data synchronization mechanism will have to
transfer larger chunks of the data structure in which a possible change
happened. On the other hand, a shallower tree consumes less memory.
The depth must be between 2 and 27 (exclusive). The default depth is 10.
True if the merkle tree is enabled, false otherwise.
Sets how many IDs are pre-fetched on the background when one call to
FlakeIdGenerator.newId() is made. Value must be in the range 1..100,000, default
is 100.
This setting pertains only to newId() calls made on the member that configured it.
Sets for how long the pre-fetched IDs can be used. If this time elapses, a new batch of IDs
will be fetched. Time unit is milliseconds, default is 600,000 (10 minutes).
The IDs contain timestamp component, which ensures rough global ordering of IDs. If an
ID is assigned to an object that was created much later, it will be much out of order. If you
don't care about ordering, set this value to 0.
This setting pertains only to newId() calls made on the member that configured it.
Sets the offset of timestamp component. Time unit is milliseconds, default is 1514764800000
(1.1.2018 0:00 UTC).
Sets the offset that will be added to the node ID assigned to cluster member for this generator.
Might be useful in A/B deployment scenarios where you have cluster A which you want to upgrade.
You create cluster B and for some time both will generate IDs and you want to have them unique.
In this case, configure node ID offset for generators on cluster B.
Sets the bit-length of the sequence component, default is 6 bits.
Sets the bit-length of node id component. Default value is 16 bits.
Sets how far to the future is the generator allowed to go to generate IDs without blocking, default is 15 seconds.
True (default) if statistics gathering is enabled on the Flake ID Generator, false otherwise.
Name of the ID generator.
Number of replicas on which the CRDT state will be kept. The updates are replicated
asynchronously between replicas.
The number must be greater than 1 and up to 2147483647 (Integer.MAX_VALUE).
The default value is 2147483647 (Integer.MAX_VALUE).
Adds the Split Brain Protection for this data-structure which you configure using the split-brain-protection element.
You should set the split-brain-protection-ref's value as the split brain protection's name.
True (default) if statistics gathering is enabled on the PN counter, false otherwise.
Name of the PN counter.
Allows to configure Memcache text protocol.
Specifies whether the Memcache text protocol support is enabled. Default value is false.
IMPORTANT
This configuration is not intended to provide addresses of other cluster members with
which the hazelcast instance will form a cluster. This is an SPI for advanced use in
cases where the DefaultAddressPicker does not pick suitable addresses to bind to
and publish to other cluster members. For instance, this could allow easier
deployment in some cases when running on Docker, AWS or other cloud environments.
That said, if you are just starting with Hazelcast, you will probably want to
set the member addresses by using the tcp-ip or multicast configuration
or adding a discovery strategy.
Member address provider allows to plug in own strategy to customize:
1. What address Hazelcast will bind to
2. What address Hazelcast will advertise to other members on which they can bind to
In most environments you don't need to customize this and the default strategy will work just
fine. However in some cloud environments the default strategy does not make the right choice and
the member address provider delegates the process of address picking to external code.
Indicates whether the advanced network configuration is enabled or not. Default is false.
Controls access to Hazelcast HTTP REST API.
The methods available through REST API are grouped to several REST endpoint groups.
There are 2 levels of configuration:
- a global switch which enables/disables access to the REST API;
- REST endpoint group level switch. It is used to check which groups are allowed once the global switch is enabled.
Enables or disables named REST endpoint group.
If a group is not listed within the rest-api configuration, then it's 'enabledByDefault' flag is used
to control the behavior of the group.
Specifies whether the HTTP REST API is enabled. Default value is false.
DEPRECATED. Please use PERSISTENCE endpoint group instead.
Note: We define PERSISTENCE and HOT_RESTART endpoint group
names as alias of each other and these names actually refer to
the same endpoint group. We're using PERSISTENCE as canonical name
for this group while listing enabled endpoint groups. If this
group enabled by using any of these name, Hazelcast will activate
this PERSISTENCE endpoint group. HOT_RESTART endpoint group name
will be removed in a future release.
By default, Hazelcast lets the system pick up an ephemeral port during socket bind operation.
But security policies/firewalls may require to restrict outbound ports to be used by
Hazelcast-enabled applications. To fulfill this requirement, you can configure Hazelcast to use
only defined outbound ports.
outbound-ports has the ports attribute to allow you to define outbound ports.
Name of the endpoint configuration. When using MEMBER or CLIENT protocol types,
name is irrelevant as a single MEMBER and CLIENT endpoint config is allowed.
The ports which Hazelcast will use to communicate between cluster members. Its default value is
5701.
It has the following attributes.
port-count: The default value is 100, meaning that Hazelcast will try to bind 100 ports.
If you set the value of port as 5701, as members join the cluster, Hazelcast tries to find
ports between 5701 and 5801. You can change the port count in cases like having large
instances on a single machine or you are willing to have only a few ports assigned.
auto-increment: Default value is true. If port is set to 5701, Hazelcast will try to find free
ports between 5701 and 5801. Normally, you will not need to change this value, but it comes
in handy when needed. You may also want to choose to use only one port. In that case, you can
disable the auto-increment feature of port by setting its value as false.
Overrides the public address of a node. By default, a node selects its socket address
as its public address. But behind a network address translation (NAT), two endpoints (nodes)
may not be able to see/access each other. If both nodes set their public addresses to their
defined addresses on NAT, then they can communicate with each other. In this case, their
public addresses are not an address of a local network interface but a virtual address defined by
NAT.
This is optional to set and useful when you have a private cloud.
When you shutdown a cluster member, the server socket port will be in the TIME_WAIT
state for the next couple of minutes. If you start the member right after shutting it down,
you may not be able to bind it to the same port because it is in the TIME_WAIT state. If you
set reuse-address to true, the TIME_WAIT state is ignored and you can bind the member to the
same port again. Default value is false.
By default, Hazelcast lets the system pick up an ephemeral port during socket bind operation.
But security policies/firewalls may require to restrict outbound ports to be used by
Hazelcast-enabled applications. To fulfill this requirement, you can configure Hazelcast to use
only defined outbound ports.
outbound-ports has the ports attribute to allow you to define outbound ports.
Name of the endpoint configuration. Only relevant when defining WAN server sockets.
Controls access to Hazelcast HTTP REST API.
The methods available through REST API are grouped to several REST endpoint groups, which can be specified
in this section.
The ports which Hazelcast will use to communicate between cluster members. Its default value is
5701.
It has the following attributes.
port-count: The default value is 100, meaning that Hazelcast will try to bind 100 ports.
If you set the value of port as 5701, as members join the cluster, Hazelcast tries to find
ports between 5701 and 5801. You can change the port count in cases like having large
instances on a single machine or you are willing to have only a few ports assigned.
auto-increment: Default value is true. If port is set to 5701, Hazelcast will try to find free
ports between 5701 and 5801. Normally, you will not need to change this value, but it comes
in handy when needed. You may also want to choose to use only one port. In that case, you can
disable the auto-increment feature of port by setting its value as false.
Overrides the public address of a node. By default, a node selects its socket address
as its public address. But behind a network address translation (NAT), two endpoints (nodes)
may not be able to see/access each other. If both nodes set their public addresses to their
defined addresses on NAT, then they can communicate with each other. In this case, their
public addresses are not an address of a local network interface but a virtual address defined by
NAT.
This is optional to set and useful when you have a private cloud.
When you shutdown a cluster member, the server socket port will be in the TIME_WAIT
state for the next couple of minutes. If you start the member right after shutting it down,
you may not be able to bind it to the same port because it is in the TIME_WAIT state. If you
set reuse-address to true, the TIME_WAIT state is ignored and you can bind the member to the
same port again. Default value is false.
By default, Hazelcast lets the system pick up an ephemeral port during socket bind operation.
But security policies/firewalls may require to restrict outbound ports to be used by
Hazelcast-enabled applications. To fulfill this requirement, you can configure Hazelcast to use
only defined outbound ports.
outbound-ports has the ports attribute to allow you to define outbound ports.
Enables or disables named REST endpoint groups.
If a group is not listed within the rest-api configuration, then it's 'enabledByDefault' flag is used
to control the behavior of the group.
Name of the endpoint configuration. When using MEMBER or CLIENT protocol types,
name is irrelevant as a single MEMBER and CLIENT endpoint config is allowed.
Enables or disables named REST endpoint group.
If a group is not listed within the rest-api configuration, then it's 'enabledByDefault' flag is used
to control the behavior of the group.
Number of CP members to initialize CP Subsystem. It is 0 by default,
meaning that CP Subsystem is disabled. CP Subsystem is enabled when
a positive value is set. After CP Subsystem is initialized successfully,
more CP members can be added at run-time and the number of active CP
members can go beyond the configured CP member count. The number of CP
members can be smaller than total member count of the Hazelcast cluster.
For instance, you can run 5 CP members in a Hazelcast cluster of
20 members. If set, must be greater than or equal to group-size.
Number of CP members to form CP groups. If set, it must be an odd
number between 3 and 7.
Otherwise, cp-member-count is respected while forming CP groups.
If set, must be smaller than or equal to cp-member-count.
Duration for a CP session to be kept alive after the last received
session heartbeat. A CP session is closed if no session heartbeat is
received during this duration. Session TTL must be decided wisely. If
a very small value is set, a CP session can be closed prematurely if
its owner Hazelcast instance temporarily loses connectivity to CP
Subsystem because of a network partition or a GC pause. In such an
occasion, all CP resources of this Hazelcast instance, such as
FencedLock or ISemaphore, are released. On the other
hand, if a very large value is set, CP resources can remain assigned to
an actually crashed Hazelcast instance for too long and liveliness
problems can occur. CP Subsystem offers an API in
CPSessionManagementService to deal with liveliness issues
related to CP sessions. In order to prevent premature session expires,
session TTL configuration can be set a relatively large value and
CPSessionManagementService#forceCloseSession(String, long)
can be manually called to close CP session of a crashed Hazelcast
instance.
Must be greater than session-heartbeat-interval-seconds, and
smaller than or equal to missing-cp-member-auto-removal-seconds.
Interval for the periodically-committed CP session heartbeats.
A CP session is started on a CP group with the first session-based
request of a Hazelcast instance. After that moment, heartbeats are
periodically committed to the CP group.
Must be smaller than session-time-to-live-seconds.
Duration to wait before automatically removing a missing CP member from
CP Subsystem. When a CP member leaves the Hazelcast cluster, it is not
automatically removed from CP Subsystem, since it could be still alive
and left the cluster because of a network problem. On the other hand,
if a missing CP member actually crashed, it creates a danger for CP
groups, because it is still part of majority calculations. This
situation could lead to losing majority of CP groups if multiple CP
members leave the cluster over time.
With the default configuration, missing CP members are automatically
removed from CP Subsystem after 4 hours. This feature is very useful
in terms of fault tolerance when CP member count is also configured
to be larger than group size. In this case, a missing CP member is
safely replaced in its CP groups with other available CP members
in CP Subsystem. This configuration also implies that no network
partition is expected to be longer than the configured duration.
If a missing CP member comes back alive after it is removed from CP
Subsystem with this feature, that CP member must be terminated manually.
Must be greater than or equal to session-time-to-live-seconds.
Offers a choice between at-least-once and at-most-once execution
of operations on top of the Raft consensus algorithm. It is disabled by
default and offers at-least-once execution guarantee. If enabled, it
switches to at-most-once execution guarantee. When you invoke an API
method on a CP data structure proxy, it sends an internal operation
to the corresponding CP group. After this operation is committed on
the majority of this CP group by the Raft leader node, it sends
a response for the public API call. If a failure causes loss of
the response, then the calling side cannot determine if the operation is
committed on the CP group or not. In this case, if this configuration is
disabled, the operation is replicated again to the CP group, and hence
could be committed multiple times. If it is enabled, the public API call
fails with com.hazelcast.core.IndeterminateOperationStateException.
Flag to denote whether or not CP Subsystem Persistence is enabled.
If enabled, CP members persist their local CP data to stable storage and
can recover from crashes.
Base directory to store all CP data when persistence-enabled
is true. This directory can be shared between multiple CP members.
Each CP member creates a unique directory for itself under the base
directory. This is especially useful for cloud environments where CP
members generally use a shared filesystem.
DEPRECATED. Please leave it to default.
Timeout duration for CP members to restore their data from disk.
A CP member fails its startup if it cannot complete its CP data restore
process in the configured duration.
Contains configuration options for Hazelcast's Raft consensus algorithm implementation
Configurations for CP semaphore instances
Configurations for FencedLock instances
Leader election timeout in milliseconds. If a candidate cannot win
majority of the votes in time, a new leader election round is initiated.
Duration in milliseconds for a Raft leader node to send periodic
heartbeat messages to its followers in order to denote its liveliness.
Periodic heartbeat messages are actually append entries requests and
can contain log entries for the lagging followers. If a too small value
is set, heartbeat messages are sent from Raft leaders to followers too
frequently and it can cause an unnecessary usage of CPU and network.
Maximum number of missed Raft leader heartbeats for a follower to
trigger a new leader election round. For instance, if
leader-heartbeat-period-in-millis is 1 second and this value is set
to 5, then a follower triggers a new leader election round if 5 seconds
pass after the last heartbeat message of the current Raft leader node.
If this duration is too small, new leader election rounds can be
triggered unnecessarily if the current Raft leader temporarily slows
down or a network congestion occurs. If it is too large, it takes longer
to detect failures of Raft leaders.
Maximum number of Raft log entries that can be sent as a batch
in a single append entries request. In Hazelcast's Raft consensus
algorithm implementation, a Raft leader maintains a separate replication
pipeline for each follower. It sends a new batch of Raft log entries to
a follower after the follower acknowledges the last append entries
request sent by the leader.
Number of new commits to initiate a new snapshot after the last snapshot
taken by the local Raft node. This value must be configured wisely as it
effects performance of the system in multiple ways. If a small value is
set, it means that snapshots are taken too frequently and Raft nodes keep
a very short Raft log. If snapshots are large and CP Subsystem
Persistence is enabled, this can create an unnecessary overhead on IO
performance. Moreover, a Raft leader can send too many snapshots to
followers and this can create an unnecessary overhead on network.
On the other hand, if a very large value is set, it can create a memory
overhead since Raft log entries are going to be kept in memory until
the next snapshot.
Maximum number of uncommitted log entries in the leader's Raft log
before temporarily rejecting new requests of callers. Since Raft leaders
send log entries to followers in batches, they accumulate incoming
requests in order to improve the throughput. You can configure this
field by considering your degree of concurrency in your callers.
For instance, if you have at most 1000 threads sending requests to
a Raft leader, you can set this field to 1000 so that callers do not
get retry responses unnecessarily.
Timeout duration in milliseconds to apply backoff on append entries
requests. After a Raft leader sends an append entries request to
a follower, it will not send a subsequent append entries request either
until the follower responds or this timeout occurs. Backoff durations
are increased exponentially if followers remain unresponsive.
Name of the CP semaphore
Enables / disables JDK compatibility of CP ISemaphore.
When it is JDK compatible, just as in the Semaphore#release()
method, a permit can be released without acquiring it first, because
acquired permits are not bound to threads. However, there is no
auto-cleanup mechanism for acquired permits upon Hazelcast
server / client failures. If a permit holder fails, its permits must be
released manually. When JDK compatibility is disabled,
a HazelcastInstance must acquire permits before releasing them
and it cannot release a permit that it has not acquired. It means, you
can acquire a permit from one thread and release it from another thread
using the same HazelcastInstance, but not different
HazelcastInstances. In this mode, acquired permits are
automatically released upon failure of the holder
HazelcastInstance. So there is a minor behavioral difference
to the Semaphore#release() method.
JDK compatibility is disabled by default.
Number of permits to initialize the Semaphore. If a positive value is
set, the Semaphore is initialized with the given number of permits.
Name of the FencedLock
Maximum number of reentrant lock acquires. Once a caller acquires
the lock this many times, it will not be able to acquire the lock again,
until it makes at least one unlock() call.
By default, no upper bound is set for the number of reentrant lock
acquires, which means that once a caller acquires a FencedLock,
all of its further lock() calls will succeed. However, for instance,
if you set lock-acquire-limit to 2, once a caller acquires
the lock, it will be able to acquire it once more, but its third lock()
call will not succeed.
If lock-acquire-limit is set to 1, then the lock becomes non-reentrant.
Sets the metrics collection frequency in seconds.
By default, metrics are collected every 5 seconds.
May be overridden by 'hazelcast.metrics.collection.frequency'
system property.
Master-switch for the metrics system. Controls whether
the metrics are collected and publishers are enabled.
May be overridden by 'hazelcast.metrics.enabled'
system property.
Sets the number of seconds the metrics will be retained on the
instance. By default, metrics are retained for 5 seconds (that is for
one collection of metrics values, if default "collection-frequency-seconds"
collection frequency is used). More retention means more heap memory, but
allows for longer client hiccups without losing a value (for example to
restart the Management Center).
May be overridden by 'hazelcast.metrics.mc.retention'
system property.
Controls whether the metrics collected are exposed to
Hazelcast Management Center. It is enabled by default.
Please note that the metrics are polled by the
Hazelcast Management Center, hence the members need to
buffer the collected metrics between two polls. The aim
for this switch is to reduce memory consumption of the
metrics system if the Hazelcast Management Center is not
used.
In order to expose the metrics, the metrics system need
to be enabled via the enabled master-switch attribute.
May be overridden by 'hazelcast.metrics.mc.enabled'
system property.
Controls whether the metrics collected are exposed to
through JMX. It is enabled by default.
In order to expose the metrics, the metrics system need
to be enabled via the enabled master-switch attribute.
May be overridden by 'hazelcast.metrics.jmx.enabled'
system property.
Configures tracking of a running Hazelcast instance. For now, this is
limited to writing information about the Hazelcast instance to a file
while the instance is starting.
The file is overwritten on every start of the Hazelcast instance and if
multiple instance share the same file system, every instance will
overwrite the tracking file of a previously started instance.
If this instance is unable to write the file, the exception is logged and
the instance is allowed to start.
Sets the name of the file which will contain the tracking metadata. If left unset
a file named "Hazelcast.process" will be created in the directory as returned by
System.getProperty("java.io.tmpdir").
The filename can contain placeholders that will be resolved in the same way
as placeholders for the format pattern.
Sets the pattern used to render the contents of the instance tracking file.
It may contain placeholders for these properties:
- "product": The instance product name, e.g. "Hazelcast" or "Hazelcast Enterprise".
- "version": The instance version.
- "mode": The instance mode which can be "server", "embedded" or "client".
- "start_timestamp": The timestamp of when the instance was started expressed the difference,
measured in milliseconds, between the current time and midnight, January 1, 1970 UTC
- "licensed": If this instance is using a license or not. The value 0 signifies
that there is no license set and the value 1 signifies that a license is in use.
- "pid": Attempts to get the process ID value. The algorithm does not guarantee to get the
process ID on all JVMs and operating systems so please test before use. In case we are unable to
get the PID, the value will be -1.
The placeholders are defined by a $HZ_INSTANCE_TRACKING{ prefix and followed by }.
For instance, a placeholder for the "start_timestamp" would be
$HZ_INSTANCE_TRACKING{start_timestamp}.
The placeholders are resolved in a fail-safe manner. Any incorrect syntax
is ignored and only the known properties are resolved, placeholders for
any parameters which do not have defined values will be ignored. This also
means that if there is a missing closing bracket in one of the placeholders,
the property name will be resolved as anything from the opening bracket
to the next closing bracket, which might contain additional opening brackets.
If unset, a JSON formatted output will be used.
Enables or disables instance tracking.
SQL service configuration.
Sets the timeout in milliseconds that is applied to SQL statements without an explicit timeout.
It is possible to set a timeout through the SqlStatement.setTimeout(long) method. If the statement
timeout is not set, then the value of this parameter will be used.
Zero value means no timeout. Negative values are prohibited.
Jet configuration.
Deprecated, use `jet` tag to configure the fields directly.
General configuration options pertaining to a Jet instance.
Sets the number of threads each cluster member will use to execute Jet
jobs. This refers only to threads executing `cooperative`
processors; each `blocking` processor is assigned its own thread.
While executing a Jet job there is the issue of regulating the rate
at which one member of the cluster sends data to another member. The
receiver will regularly report to each sender how much more data it
is allowed to send over a given DAG edge. This method sets the length
(in milliseconds) of the interval between flow-control ("ack") packets.
Sets the number of backups that Jet will maintain for the job metadata
and snapshots. Each backup is on another cluster member; all backup
write operations must complete before the overall write operation can
complete. The maximum allowed number of backups is 6 and the default is
1.
For example, if you set the backup count to 2, Jet will replicate all
the job metadata and snapshot data to two other members. If one or two
members of the cluster fail, Jet can recover the data from the snapshot
and continue executing the job on the remaining members without loss.
Sets the delay after which auto-scaled jobs will restart if a new member
is added to the cluster. The default is 10 seconds. Has no effect on
jobs with auto scaling disabled.
Sets whether lossless job restart is enabled for the node. With lossless
restart you can restart the whole cluster without losing the jobs and
their state. The feature is implemented on top of the Hot Restart
feature of Hazelcast which persists the data to disk. If enabled, you
have to also configure Hot Restart.
Note: the snapshots exported using `Job#exportSnapshot` will also have
Hot Restart storage enabled.
Feature is disabled by default. If you enable this option in open-source,
the member will fail to start, you need Enterprise to run it and obtain a
license from Hazelcast.
Sets the maximum number of records that can be accumulated by any single
processor instance.
Operations like grouping, sorting or joining require certain amount of
records to be accumulated before they can proceed. You can set this option
to reduce the probability of OutOfMemoryError.
This option applies to each processor instance separately, hence the
effective limit of records accumulated by each cluster member is influenced
by the vertex's localParallelism and the number of jobs in the cluster.
Currently, maxProcessorAccumulatedRecords limits:
1. number of items sorted by the sort operation
2. number of distinct keys accumulated by aggregation operations
3. number of entries in each hash-join lookup table
4. number of entries in stateful transforms
5. number of distinct items in distinct operation
Note: the limit does not apply to streaming aggregations.
The default value is Long.MAX_VALUE.
Sets the number of threads each cluster member will use to execute Jet
jobs. This refers only to threads executing `cooperative`
processors; each `blocking` processor is assigned its own thread.
While executing a Jet job there is the issue of regulating the rate
at which one member of the cluster sends data to another member. The
receiver will regularly report to each sender how much more data it
is allowed to send over a given DAG edge. This method sets the length
(in milliseconds) of the interval between flow-control ("ack") packets.
Sets the number of backups that Jet will maintain for the job metadata
and snapshots. Each backup is on another cluster member; all backup
write operations must complete before the overall write operation can
complete. The maximum allowed number of backups is 6 and the default is
1.
For example, if you set the backup count to 2, Jet will replicate all
the job metadata and snapshot data to two other members. If one or two
members of the cluster fail, Jet can recover the data from the snapshot
and continue executing the job on the remaining members without loss.
Sets the delay after which auto-scaled jobs will restart if a new member
is added to the cluster. The default is 10 seconds. Has no effect on
jobs with auto scaling disabled.
Sets whether lossless job restart is enabled for the node. With lossless
restart you can restart the whole cluster without losing the jobs and
their state. The feature is implemented on top of the Hot Restart
feature of Hazelcast which persists the data to disk. If enabled, you
have to also configure Hot Restart.
Note: the snapshots exported using `Job#exportSnapshot` will also have
Hot Restart storage enabled.
Feature is disabled by default. If you enable this option in open-source,
the member will fail to start, you need Enterprise to run it and obtain a
license from Hazelcast.
Sets the maximum number of records that can be accumulated by any single
processor instance.
Operations like grouping, sorting or joining require certain amount of
records to be accumulated before they can proceed. You can set this option
to reduce the probability of OutOfMemoryError.
This option applies to each processor instance separately, hence the
effective limit of records accumulated by each cluster member is influenced
by the vertex's localParallelism and the number of jobs in the cluster.
Currently, maxProcessorAccumulatedRecords limits:
1. number of items sorted by the sort operation
2. number of distinct keys accumulated by aggregation operations
3. number of entries in each hash-join lookup table
4. number of entries in stateful transforms
5. number of distinct items in distinct operation
Note: the limit does not apply to streaming aggregations.
The default value is Long.MAX_VALUE.
A configuration object for a DAG `Edge` that holds fine-tuning parameters
that influence its performance characteristics.
Sets the capacity of processor-to-processor concurrent queues. The value
is rounded upwards to the next power of 2.
When data needs to travel between two processors on the same cluster
member, Jet sends it over a concurrent single-producer, single-consumer
(SPSC) queue of fixed capacity.
Since there are several processors executing the logic of each vertex,
and since the queues are SPSC, there will be
`senderParallelism * receiverParallelism` queues representing the edge on
each member. The edge capacity should strike a balance between
performance and memory usage.
For a distributed edge, data is sent to a remote member via Hazelcast network
packets. Each packet is dedicated to the data of a single edge, but may contain
any number of data items. This setting limits the size of the packet in bytes.
Packets should be large enough to drown out any fixed overheads, but small enough
to allow good interleaving with other packets.
Note that a single item cannot straddle packets, therefore the maximum packet size
can exceed the value configured here by the size of a single data item.
This setting has no effect on a non-distributed edge.
Sets the scaling factor used by the adaptive receive window sizing
function.
For each distributed edge the receiving member regularly sends
flow-control ("ack") packets to its sender which prevent it from sending
too much data and overflowing the buffers. The sender is allowed to send
the data one `receive window` further than the last acknowledged byte and
the receive window is sized in proportion to the rate of processing at
the receiver.
Ack packets are sent in regular intervals (InstanceConfig#setFlowControlPeriodMs)
and the `receive window multiplier` sets the factor of the linear
relationship between the amount of data processed within one such
interval and the size of the receive window.
To put it another way, let us define an `ackworth` as the amount of data
processed between two consecutive ack packets. The receive window
multiplier determines the number of ackworths the sender can be ahead of
the last acked byte.
This setting has no effect on a non-distributed edge.
Specifies whether the Jet Service is enabled or not. Values can be true or false.
Specifies whether the resource uploading for Jet jobs is enabled or not.
Values can be true or false.