socket-timeoutlong60000 Enable/disable SO_TIMEOUT on socket connections to remote Hot Rod servers with the specified timeout, in milliseconds. A timeout of zero is interpreted as an infinite timeout.
tcp-no-delaybooleantrue Enable/disable TCP_NODELAY on socket connections to remote Hot Rod servers.
hotrod-wrappingbooleanfalse Ensures that, when entries are retrieved from the remote store, they will be wrapped in a format suitable for serving via HotRod. This flag must be enabled when performing a rolling upgrade
raw-valuesbooleanfalse Enables the storage of data on the remote server in "raw" format as opposed to wrapping the entries in InternalCacheEntry. This will make the remote cache interoperable between direct RemoteCacheManager clients and RemoteCacheStore stores
balancing-strategystringorg.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy For replicated (vs distributed) Hot Rod server clusters, the client balances requests to the servers according to this strategy.
connect-timeoutint60000 This property defines the maximum socket connect timeout before giving up connecting to the server.
force-return-valuesbooleanfalse Whether or not to implicitly FORCE_RETURN_VALUE for all calls.
key-size-estimateint64 Deprecated since 12.0, does nothing and will be removed in 15.0
marshallerstring Allows you to specify a custom {@link org.infinispan.marshall.Marshaller} implementation to serialize and deserialize user objects.
protocol-versionstring3.1 This property defines the protocol version that this client should use. Defaults to 1.1. Other valid values include 1.0.
cachestring The name of the remote cache in the remote infinispan cluster, to which to connect to. If unspecified, the default cache will be used
value-size-estimateint512 Deprecated since 12.0, does nothing and will be removed in 15.0



Configuration of the connection pool

EXCEPTION An exception will be thrown to the calling user
WAIT The caller will block (invoke waits until a new or idle connections is available).
CREATE_NEW A new persistent connection will be created and returned (essentially making maxActive meaningless.)
Specifies what happens when asking for a connection from a server's pool, and that pool is exhausted.
max-activeint-1 Controls the maximum number of connections per server that are allocated (checked out to client threads, or idle in the pool) at one time. When non-positive, there is no limit to the number of connections per server. When maxActive is reached, the connection pool for that server is said to be exhausted. The default setting for this parameter is -1, i.e. there is no limit.
min-idleint-1 Sets a target value for the minimum number of idle connections (per server) that should always be available. If this parameter is set to a positive number and timeBetweenEvictionRunsMillis > 0, each time the idle connection eviction thread runs, it will try to create enough idle instances so that there will be minIdle idle instances available for each server. The default setting for this parameter is 1.
max-pending-requestsint5 Specifies maximum number of requests sent over single connection at one instant. Connections with more concurrent requests will be ignored in the pool when choosing available connection and the pool will try to create a new connection if all connections are utilized. Only if the new connection cannot be created and the exhausted action is set to WAIT the pool will allow sending the request over one of the over-utilized connections. The rule of thumb is that this should be set to higher values if the values are small (< 1kB) and to lower values if the entries are big (> 10kB). Default setting for this parameter is 5.
min-evictable-idle-timelong1800000 Specifies the minimum amount of time that an connection may sit idle in the pool before it is eligible for eviction due to idle time. When non-positive, no connection will be dropped from the pool due to idle time alone. This setting has no effect unless timeBetweenEvictionRunsMillis > 0. The default setting for this parameter is 1800000(30 minutes).


Configuration for the executor service used for asynchronous work on the Transport, including asynchronous marshalling and Cache 'async operations' such as Cache.putAsync().

factorystring Fully qualified class name of the ExecutorFactory to use. Must implement org.infinispan.executors.ExecutorFactory


Add key/value property pair to this factory configuration. Example properties include "maxThreads" which sets the maximum number of threads for this executor and "threadNamePrefix" which sets the thread name prefix for threads created by this executor ( default values can be found at https://docs.jboss.org/author/display/ISPN/Default+Values+For+Property+Based+Attributes ).


Hot Rod Security configuration.


Hot Rod authentication configuration

server-namestring The SASL server name


usernamestring The username to use when connecting
passwordstring The password to use when connecting


usernamestring The username to use when connecting
passwordstring The password to use when connecting
realmstring The realm to use when connecting



Hot Rod encryption configuration

protocolstringTLSv1.2 The TLS/SSL protocol to use. Defaults to TLSv1.2
sni-hostnamestring The SNI hostname to use when connecting.


certificate-passwordstring The password to use when obtaining the certificate from the key store. If not specified, the password will be used.
key-aliasstring If the key store contains multiple keys, use the one with the specified alias
filenamestring The path to the key store.
passwordstring The password to use to access the key store.
typestringJKS The key store type (JKS, JCEKS).


filenamestring The path to the key store.
passwordstring The password to use to access the key store.
typestringJKS The key store type (JKS, JCEKS).
sharedbooleanfalseThis setting should be set to true when multiple cache instances share the same cache store (e.g., multiple nodes in a cluster using a JDBC-based CacheStore pointing to the same, shared database.) Setting this to true avoids multiple cache instances writing the same modification multiple times. If enabled, only the node where the modification originated will write to the cache store. If disabled, each individual cache reacts to a potential remote update by storing the data to the cache store.
transactionalbooleanfalseThis setting should be set to true when the underlying cache store supports transactions and it is desirable for the underlying store and the cache to remain synchronized. With this enabled any Exceptions thrown whilst writing to the underlying store will result in both the store's and cache's transactions rollingback.
preloadbooleanfalseIf true, when the cache starts, data stored in the cache store will be pre-loaded into memory. This is particularly useful when data in the cache store will be needed immediately after startup and you want to avoid cache operations being delayed as a result of loading this data lazily. Can be used to provide a 'warm-cache' on startup, however there is a performance penalty as startup time is affected by this process. Likewise in some cases you cannot pre-load data in caches stores, such as when using shared remote stores.
fetch-statebooleanfalseFetches the persistent state of a cache when joining a cluster. Values are true / false (default). The purpose of this property is to retrieve the persistent state of a cache and apply it to the local cache store of a node when it joins a cluster. Fetching the persistent state does not apply if a cache store is shared because it accesses the same data as the other stores. This property can be `true` for one configured cache loader only. If more than one cache loader fetches the persistent state, a configuration exception is thrown when the cache service starts.
purgebooleanfalse Empties the specified cache loader at startup. Values are true / false (default). This property takes effect only if read-only is false.
read-onlybooleanfalse Prevents data from being persisted to cache stores. Values are true / false (default). If true, cache stores load entries only. Any modifications to data in the cache do not apply to cache stores.
write-onlybooleanfalse Prevents data from being loaded from cache stores. Values are true / false (default). If true, cache stores write entries only. Any retrievals of data in the cache do not read from the cache store.
max-batch-sizeint100 Sets the maximum size of a batch to insert or delete from the cache store. If the value is less than one, no upper limit applies to the number of operations in a batch.
segmentedbooleantrue Configures cache stores to store data in hash space segments, with the cache's "segments" attribute defining the number of segments.


Configures cache stores as write-behind instead of write-through.

modification-queue-sizeint1024 Specifies the maximum number of entries in the asynchronous modification queue. When the queue is full, write-through mode is used until the queue can accept new entries.
thread-pool-sizeint1 Specifies the number of threads to apply modifications to the cache store.
fail-silentlybooleanfalse Controls how asynchronous write operations take place when cache stores become unavailable. If "true", asynchronous write operations that fail are re-attempted with the number of times specified in the "connection-attempts" parameter. If all attempts fail, errors are ignored and write operations are not executed on the cache store. If "false", asynchronous write operations that fail are re-attempted when the underlying store becomes available. If the modification queue becomes full before the underlying store becomes available, an error is thrown on all future write operations to the store until the modification queue is flushed. The modification queue is not persisted. If the underlying store does not become available before the asynchronous store is stopped, queued modifications are lost.


Defines a cache store property with name and value.

Expand/Collapse All