Infinispan Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
 
(115 intermediate revisions by the same user not shown)
Line 2: Line 2:


* [[Infinispan#Subjects|Infinispan]]
* [[Infinispan#Subjects|Infinispan]]
* [[WildFly Infinispan Subsystem Concepts]]
=Relevance=
* JDG 7.0
=Usage Modes=
==Remote Client-Server Mode==
{{External|[https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html/getting_started_guide/red_hat_jboss_data_grid#remote_client_server_mode JDG 7.1 Getting Started Guide]}}
In client-server mode, the Infinispan server runs as a separate data grid server. The data grid may contain one or multiple clustered Infinispan nodes. Each Infinispan node in client-server mode runs as a self-contianed process using a container based on [[WildFly]]. For more than one node, the nodes cluster over JGroups.
The client applications can access the data grid sever using [[Infinispan Hot Rod|Hot Rod]], [[memcached]] and [[REST and Hypermedia|REST]] client APIs.
An Infinispan server in client-server mode does NOT offer transactional operations. [[#Transactions|Transactional operations]] are available only in [[#Library_Mode|library mode]].
However, the client-server mode allows for easy scalability, by just adding nodes, and easier upgrades of the data grid without impact on client application.
{{Internal|Installation of JDG in Remote Client-Server Mode within EAP|JDG Installation - Remote Client-Server Mode within EAP}}
{{Internal|JDG Remote Client-Server Mode Usage Example|JDG Remote Client-Server Mode Usage Example}}
==Library Mode==
{{External|[https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html/getting_started_guide/red_hat_jboss_data_grid#library_mode JDG 7.1 Getting Started Guide]}}
In ''library mode'', a data grid node is collocated with the application within the same JVM. In case the data grid contains multiple nodes, those nodes cluster with each over over JGroups.
[[#Transactions|Transactions]], <font color=red>listeners and notifications (clarify this, it seems to work)</font> can be used in library mode, but not in [[#Remote_Client-Server_Mode|remote client-server mode]].
{{Internal|Installation of JDG in Library Mode within EAP|JDG Installation - Library Mode within EAP}}
{{Internal|JDG in Library Mode Usage Example|JDG in Library Mode Usage Example}}
=Cache Modes=
==Local Mode==
==Distributed Mode==
<font color=red>Clarify the machine/rack/site affinity.</font>
==Replicated Mode==
==Invalidation Mode==
External: http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#invalidation_mode
The number of invalidation events is collected and exposed as the [[Infinispan_Cache_Metrics#Invalidations|invalidations]] cache metric.
=Eviction=
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Infinispan Eviction]]
</blockquote>
=Passivation=
The process of writing into a store data that is being evicted from memory is named ''passivation''. Also see [[#Cache_Store_Passivation|Cache Store Passivation]].
<font color=red>TODO process http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#cache-passivation</font>.
=Activation=
The process of bringing an entry in memory from a cache store. Also see [[#Cache_Store_Activation|Cache Store Activation]].
=Expiration=
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Infinispan Expiration]]
</blockquote>


=Cache Container=
=Cache Container=


A ''cache container'' is the runtime structure that instantiates and manages one or more caches. In case of clustered caches, the cache container encapsulates the networking mechanisms required to maintain state across more than one JVM for its caches, including a JGroups stack. The cache container implementations are heavyweight objects. There should be possible to use just one cache container per JVM, unless specific configuration requires the availability of more than one instance - but in this case there will be a minimal and finite number of such instances.
A ''cache container'' is the runtime structure that instantiates and manages one or more caches. In case of clustered caches, the cache container encapsulates the networking mechanisms required to maintain state across more than one JVM for its caches, including a JGroups stack.  
 
Each cache container declares a set of caches that share a global configuration, so caches belonging to different cache containers can have different transport configurations, optimized for different use cases.
 
The cache container implementations are heavyweight objects. There should be possible to use just one cache container per JVM, unless specific configuration requires the availability of more than one instance - but in this case there will be a minimal and finite number of such instances.


A WildFly cache container is the WildFly service wrapper around an Infinispan cache container. Each <cache-container> element eventually results in a <tt>org.infinispan.manager.DefaultCacheManager</tt> instance being created in the JVM.
A WildFly cache container is the WildFly service wrapper around an Infinispan cache container. Each <cache-container> element eventually results in a <tt>org.infinispan.manager.DefaultCacheManager</tt> instance being created in the JVM.
Line 15: Line 90:
</blockquote>
</blockquote>


From an API perspective, the cache container is the primary API mechanism to retrieve cache instances or create cache instances on demand.
From an API perspective, the cache container is the primary API mechanism to retrieve cache instances or create cache instances on demand. For more details see:
 
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Infinispan Cache Container API|Cache Container API]]
</blockquote>
 
<font color=red>Understand the relationship between the cache-container and getting access to a specific cache container via RemoteCacheManager.</font>


==Cache Manager==
==Cache Manager==
Line 22: Line 103:


=Cache=
=Cache=
==Default Cache and Named Caches==
Each cache container has a ''default cache'' instance. A container's default cache is established via configuration. The default cache for a specific cache container is configured using the <tt>[[Infinispan_Cache_Container_Configuration#default-cache|default-cache]]</tt> configuration attribute. For JDG 7, the configuration section that declares the default cache is:
<pre>
<subsystem xmlns="urn:infinispan:server:core:..." default-cache-container="clustered">
    <cache-container name="clustered" default-cache="default" ...>
        ...
        <distributed-cache name="default" ...>
            ...
        </distributed-cache>
    </cache-container>
    ...
</subsystem>
</pre>
Note that the example above, the default cache name it just happens to be "default". The name can be any legal cache name.
The default cache can be retrieved via the <tt>CacheManager.getCache()</tt> API.
''Named caches'' are retrieved via <tt>CacheManager.getCache(String name)</tt> API. Therefore, note that the name attribute of named cache is both mandatory and unique for every named cache specified. Named caches have the same XML schema as the default cache so they inherit settings from the default cache while additional behavior can be specified or overridden.
=Persistence=
=Cache Store=
A cache store implements the <tt>CacheLoader</tt> or <tt>CacheWriter</tt> interfaces, or both.
Cache stores are deployed in a chain. A cache read operation looks at all of the installed <tt>CacheLoader</tt>s, in the order they are installed, until it finds a valid and non-null element of data. When performing writes all cache <tt>CacheWriter</tt>s are written to, except if the <tt>ignoreModifications</tt> element has been set to true for a specific cache writer
More details on cache store configuration:
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Infinispan_Cache_Container_Configuration#Cache_Store_Configuration|Cache Store Configuration]]
</blockquote>
==Cache Store Passivation==
If passivation is enabled (by default it is not), data is only written to the cache store when it is evicted from memory. Next time the data is requested, it will be 'activated' which means that data will be brought back to memory and removed from the persistent store. If the passivation is disabled, by default, the cache store contains a copy of the contents in memory, so writes to cache result in cache store writes. This essentially implements a 'write-through' behavior. The interaction between the cache and cache store during passivation is described in detail here: [[#Passivation|Passivation]].
Configuration details:
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Infinispan_Cache_Container_Configuration#passivation|Cache Container Configuration ("passivation")]]
</blockquote>
The number of passivations per node is exposed via the '[[Infinispan_Cache_Metrics#Passivations_and_Activations|passivations]]' cache metric.
==Cache Store Activation==
The process of bringing an entry in memory from a cache store.
The number of activations per node is exposed via the  '[[Infinispan_Cache_Metrics#Passivations_and_Activations|activations]]' cache metric.
==Shared Cache Store==
A shared cache store means that the cache store instance is shared among different cache instances (e.g., multiple nodes in a cluster using a JDBC-based CacheStore pointing to the same, shared database).. If "shared" is set to true prevents repeated and unnecessary writes of the same data to the cache loader by different cache instances: 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.
Configuration details:
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Infinispan_Cache_Container_Configuration#shared|Cache Container Configuration ("shared")]]
</blockquote>
==Cache Store Preloading==
If the store is configured to do preloading, when the cache starts, data stored in the cache loader will be pre-loaded into memory. This is particularly useful when data in the cache loader is 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. Note that preloading is done in a local fashion, so any data loaded is only stored locally in the node. No replication or distribution of the preloaded data happens. Also, Infinispan only preloads up to the maximum configured number of entries in eviction.
Configuration details:
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Infinispan_Cache_Container_Configuration#preload |Cache Container Configuration ("preload")]]
</blockquote>
==Cache Store Purge==
If purge is set to true, it empties the specified cache store (if ignoreModifications is false) when the cache loader starts up.
Configuration details:
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Infinispan_Cache_Container_Configuration#purge |Cache Container Configuration ("purge")]]
</blockquote>
=Cache Listeners=
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Infinispan Cache Listeners|Cache Listeners]]
</blockquote>


=Connecting to an Infinispan Server=
=Connecting to an Infinispan Server=


==HotRot==
==HotRod Connector==


<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Infinispan_Hot_Rod#HotRod_Connector|The HotRod Connector]]
</blockquote>


The HotRod connector is configured in the [[Infinispan_Configuration#infinispan:server:endpoint_Section|infinispan:server:endpoint Section]].
==memcached Connector==
 
==memcached==


The memcached connector is configured in the [[Infinispan_Configuration#infinispan:server:endpoint_Section|infinispan:server:endpoint Section]].
The memcached connector is configured in the [[Infinispan_Configuration#infinispan:server:endpoint_Section|infinispan:server:endpoint Section]].


==REST==
==REST Connector==


The REST connector is configured in the [[Infinispan_Configuration#infinispan:server:endpoint_Section|infinispan:server:endpoint Section]].
The REST connector is configured in the [[Infinispan_Configuration#infinispan:server:endpoint_Section|infinispan:server:endpoint Section]].
The REST connector activity can be logged by turning on TRACE on the "org.infinispan.rest.logging.RestAccessLoggingHandler" logger.
=HotRod=
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Infinispan Hot Rod]]
</blockquote>
=Client API=
{{Internal|Infinispan Cache Container API|Cache Container API}}
{{Internal|Infinispan Cache API|Cache API}}
{{Internal|JDG in Library Mode Usage Example|JDG in Library Mode Usage Example}}
{{Internal|JDG Remote Client-Server Mode Usage Example|JDG Remote Client-Server Mode Usage Example}}
=Cross-Site Replication=
JDG allows linking of two otherwise isolated clustered caches over a link optimized to traverse a WAN.
<font color=red>
Questions:
* How do I determine the site master(s) from CLI, logs, etc.
* RELAY connection health.
* "RELAY2 question" e-mail thread in the e-mail archive, c100 project.
* Thread pool rejection policy – the default: DISCARD -> ABORT (WARN).
* https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Data_Grid/6.6/html/Administration_and_Configuration_Guide/sect-Configure_Multiple_Site_Masters.html
* How can I have just one copy of the data that is being relay-ed to the remote cluster (cell)?
* Verify that the relationship between the original keys and replicated keys (included cross replication) holds. Take active session numbers into account.
* Can we tell which key is original, replicated as a result of distribution algorithm, and as a result of cross replication?
</font>
==RELAY Protocol==
For concepts related to the underlying JGroups RELAY2 protocol see:
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[JGroups_Protocol_RELAY2#Overview|JGroups RELAY2 Concepts]]
</blockquote>
==Site Master==
==Cross-Site Replication Configuration==
The configuration procedure is documented here:
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Bridge Two Infinsipan Clustered Caches with RELAY2]]
</blockquote>
=JNDI=
<font color=red>
This discussion has more sense in the context of the infinsipan subsystem of the EAP.
Understand how, and what caches are bound into JNDI.
jboss.naming.context.java.java:jboss/infinispan/cache/web/sso jboss.naming.context.java.java:jboss/infinispan/container/ejb jboss.naming.context.java.java:jboss/infinispan/container/hibernate jboss.naming.context.java.java:jboss/infinispan/container/singleton jboss.naming.context.java.java:jboss/infinispan/container/web
</font>
=HTTP Session Replication=
{{Internal|WildFly Infinispan HTTP Session Replication Configuration|HTTP Session Replication with Infinispan}}
{{Internal|Using JDG as External Cache Container for WildFly HTTP Session Replication|HTTP Session Externalization with JDG}}
=Second-Level JPA Cache=
<span id='Second_Level_JPA_Cache'></span>
{{Internal|Infinispan as Second Level JPA Cache|Infinispan as Second-Level JPA Cache}}
=Transactions=
{{External|https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#transactions}}
JTA transactions are supported in [[#Library_Mode|library mode]], but not in [[#Remote_Client-Server_Mode|remote client/server mode]], as per [https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html/developer_guide/transactions#configure_transactions_library_mode Red Hat documentation]. This is also obvious from the fact that <tt>org.infinispan.client.hotrod.configuration.ConfigurationBuilder</tt> lacks transactional behavior configuration methods.

Latest revision as of 21:01, 26 September 2018

Internal

Relevance

  • JDG 7.0

Usage Modes

Remote Client-Server Mode

JDG 7.1 Getting Started Guide

In client-server mode, the Infinispan server runs as a separate data grid server. The data grid may contain one or multiple clustered Infinispan nodes. Each Infinispan node in client-server mode runs as a self-contianed process using a container based on WildFly. For more than one node, the nodes cluster over JGroups.

The client applications can access the data grid sever using Hot Rod, memcached and REST client APIs.

An Infinispan server in client-server mode does NOT offer transactional operations. Transactional operations are available only in library mode.

However, the client-server mode allows for easy scalability, by just adding nodes, and easier upgrades of the data grid without impact on client application.

JDG Installation - Remote Client-Server Mode within EAP
JDG Remote Client-Server Mode Usage Example

Library Mode

JDG 7.1 Getting Started Guide

In library mode, a data grid node is collocated with the application within the same JVM. In case the data grid contains multiple nodes, those nodes cluster with each over over JGroups.

Transactions, listeners and notifications (clarify this, it seems to work) can be used in library mode, but not in remote client-server mode.

JDG Installation - Library Mode within EAP
JDG in Library Mode Usage Example

Cache Modes

Local Mode

Distributed Mode

Clarify the machine/rack/site affinity.

Replicated Mode

Invalidation Mode

External: http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#invalidation_mode

The number of invalidation events is collected and exposed as the invalidations cache metric.

Eviction

Infinispan Eviction

Passivation

The process of writing into a store data that is being evicted from memory is named passivation. Also see Cache Store Passivation.

TODO process http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#cache-passivation.

Activation

The process of bringing an entry in memory from a cache store. Also see Cache Store Activation.

Expiration

Infinispan Expiration

Cache Container

A cache container is the runtime structure that instantiates and manages one or more caches. In case of clustered caches, the cache container encapsulates the networking mechanisms required to maintain state across more than one JVM for its caches, including a JGroups stack.

Each cache container declares a set of caches that share a global configuration, so caches belonging to different cache containers can have different transport configurations, optimized for different use cases.

The cache container implementations are heavyweight objects. There should be possible to use just one cache container per JVM, unless specific configuration requires the availability of more than one instance - but in this case there will be a minimal and finite number of such instances.

A WildFly cache container is the WildFly service wrapper around an Infinispan cache container. Each <cache-container> element eventually results in a org.infinispan.manager.DefaultCacheManager instance being created in the JVM.

The corresponding WildFly/JDG configuration element is <cache-container>. The <cache-container> elements are children of the "infinispan" (for WildFly) or "infinispan:server:core:" (for JDG) subsystems. More details about cache container configuration can be found here:

Cache Container Configuration

From an API perspective, the cache container is the primary API mechanism to retrieve cache instances or create cache instances on demand. For more details see:

Cache Container API

Understand the relationship between the cache-container and getting access to a specific cache container via RemoteCacheManager.

Cache Manager

A cache manager and a cache container represent similar concepts.

Cache

Default Cache and Named Caches

Each cache container has a default cache instance. A container's default cache is established via configuration. The default cache for a specific cache container is configured using the default-cache configuration attribute. For JDG 7, the configuration section that declares the default cache is:

<subsystem xmlns="urn:infinispan:server:core:..." default-cache-container="clustered">
    <cache-container name="clustered" default-cache="default" ...>
        ...
        <distributed-cache name="default" ...>
            ...
        </distributed-cache>
    </cache-container>
    ...
</subsystem>

Note that the example above, the default cache name it just happens to be "default". The name can be any legal cache name.

The default cache can be retrieved via the CacheManager.getCache() API.

Named caches are retrieved via CacheManager.getCache(String name) API. Therefore, note that the name attribute of named cache is both mandatory and unique for every named cache specified. Named caches have the same XML schema as the default cache so they inherit settings from the default cache while additional behavior can be specified or overridden.

Persistence

Cache Store

A cache store implements the CacheLoader or CacheWriter interfaces, or both.

Cache stores are deployed in a chain. A cache read operation looks at all of the installed CacheLoaders, in the order they are installed, until it finds a valid and non-null element of data. When performing writes all cache CacheWriters are written to, except if the ignoreModifications element has been set to true for a specific cache writer

More details on cache store configuration:

Cache Store Configuration

Cache Store Passivation

If passivation is enabled (by default it is not), data is only written to the cache store when it is evicted from memory. Next time the data is requested, it will be 'activated' which means that data will be brought back to memory and removed from the persistent store. If the passivation is disabled, by default, the cache store contains a copy of the contents in memory, so writes to cache result in cache store writes. This essentially implements a 'write-through' behavior. The interaction between the cache and cache store during passivation is described in detail here: Passivation.

Configuration details:

Cache Container Configuration ("passivation")

The number of passivations per node is exposed via the 'passivations' cache metric.

Cache Store Activation

The process of bringing an entry in memory from a cache store.

The number of activations per node is exposed via the 'activations' cache metric.

Shared Cache Store

A shared cache store means that the cache store instance is shared among different cache instances (e.g., multiple nodes in a cluster using a JDBC-based CacheStore pointing to the same, shared database).. If "shared" is set to true prevents repeated and unnecessary writes of the same data to the cache loader by different cache instances: 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.

Configuration details:

Cache Container Configuration ("shared")

Cache Store Preloading

If the store is configured to do preloading, when the cache starts, data stored in the cache loader will be pre-loaded into memory. This is particularly useful when data in the cache loader is 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. Note that preloading is done in a local fashion, so any data loaded is only stored locally in the node. No replication or distribution of the preloaded data happens. Also, Infinispan only preloads up to the maximum configured number of entries in eviction.

Configuration details:

Cache Container Configuration ("preload")

Cache Store Purge

If purge is set to true, it empties the specified cache store (if ignoreModifications is false) when the cache loader starts up.

Configuration details:

Cache Container Configuration ("purge")

Cache Listeners

Cache Listeners

Connecting to an Infinispan Server

HotRod Connector

The HotRod Connector

memcached Connector

The memcached connector is configured in the infinispan:server:endpoint Section.

REST Connector

The REST connector is configured in the infinispan:server:endpoint Section.

The REST connector activity can be logged by turning on TRACE on the "org.infinispan.rest.logging.RestAccessLoggingHandler" logger.

HotRod

Infinispan Hot Rod

Client API

Cache Container API
Cache API
JDG in Library Mode Usage Example
JDG Remote Client-Server Mode Usage Example

Cross-Site Replication

JDG allows linking of two otherwise isolated clustered caches over a link optimized to traverse a WAN.

Questions:


RELAY Protocol

For concepts related to the underlying JGroups RELAY2 protocol see:

JGroups RELAY2 Concepts

Site Master

Cross-Site Replication Configuration

The configuration procedure is documented here:

Bridge Two Infinsipan Clustered Caches with RELAY2

JNDI

This discussion has more sense in the context of the infinsipan subsystem of the EAP.

Understand how, and what caches are bound into JNDI.

jboss.naming.context.java.java:jboss/infinispan/cache/web/sso jboss.naming.context.java.java:jboss/infinispan/container/ejb jboss.naming.context.java.java:jboss/infinispan/container/hibernate jboss.naming.context.java.java:jboss/infinispan/container/singleton jboss.naming.context.java.java:jboss/infinispan/container/web

HTTP Session Replication

HTTP Session Replication with Infinispan
HTTP Session Externalization with JDG

Second-Level JPA Cache

Infinispan as Second-Level JPA Cache

Transactions

https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#transactions

JTA transactions are supported in library mode, but not in remote client/server mode, as per Red Hat documentation. This is also obvious from the fact that org.infinispan.client.hotrod.configuration.ConfigurationBuilder lacks transactional behavior configuration methods.