Getting Started Guide

Red Hat JBoss Data Grid is a distributed in-memory data grid, which provides the following capabilities:

The set of supported features, configurations, and integrations for Red Hat JBoss Data Grid (current and past versions) are available at the Supported Configurations page at https://access.redhat.com/articles/115883.

Red Hat JBoss Data Grid includes many components for Library and Remote Client-Server modes. A comprehensive (and up to date) list of components included in each of these usage modes and their versions is available in the Red Hat JBoss Data Grid Component Details page at https://access.redhat.com/articles/488833

Red Hat JBoss Data Grid provides the following benefits:

Red Hat JBoss Data Grid is based on Infinispan, the open source community version of the data grid software. Infinispan uses code, designs, and ideas from JBoss Cache, which have been tried, tested, and proved in high stress environments. As a result, JBoss Data Grid’s first release is version 6.0 as a result of its deployment history.

The following table lists the correlation between JBoss Data Grid and Infinispan versions.

Figure 1.1. Red Hat JBoss Data Grid Cache Architecture

Red Hat JBoss Data Grid’s cache infrastructure depicts the individual elements and their interaction with each other in each JBoss Data Grid Usage Mode (Library and Remote Client-Server). For clarity, each cache architecture diagram is separated into two parts:

In Remote Client-Server mode, the Application does not directly interact with the cache. Additionally, the Application usually resides in a different JVM, on different physical host, or does not need to be a Java Application. In this case, the Application uses a Cache Client that communicates with a remote JBoss Data Grid Server over the network using one of the supported protocols such as Memcached, Hot Rod, or REST. The appropriate server module handles the communication on the server side. When a request is sent to the server remotely, it translates the protocol back to the concrete operations performed on the cache component to store and retrieve data.

Red Hat JBoss Data Grid provides the following programmable APIs:

JBoss Data Grid offers the following APIs to interact with the data grid in Remote Client-Server mode:

The only prerequisite to set up Red Hat JBoss Data Grid is an installed Java Virtual Machine (compatible with Java 8.0 or later).

A Java Virtual Machine (JVM) is a virtual environment that runs and executes Java programs on a host operating system. The JVM acts as an abstract computer and is a platform-independent execution environment that converts the Java programming code into machine language. A Java Virtual Machine (JVM) makes Java portable by providing an abstraction layer between the compiled Java program and the underlying hardware platform and operating system.

Red Hat recommends using OpenJDK Java platform as it is an open source, supported Java Virtual Machine that runs well on Red Hat Enterprise Linux systems. For Windows users, Oracle JDK 1.8 installation is recommended.

Apache Maven is a distributed build automation tool used in Java application development to create, manage, and build software projects. Maven uses standard configuration files called Project Object Model (POM) files to define projects and manage the build process. POM files describe the module and component dependencies, build order, and targets for the resulting project packaging and output using an XML file. This ensures that the project is built correctly and in a uniform manner.

Visit the Maven Download page (http://maven.apache.org/download.html) for instructions to download and install Maven.

Red Hat JBoss Data Grid Quickstarts require the following Maven repositories to be set up as a prerequisite:

Both Maven repositories are installed in the same way. As a result, the subsequent instructions are for both repositories.

When building projects with Maven it will discover and download the dependencies of any included libraries. These additional libraries are referred to as Transitive, or Transient, Dependencies, and are discussed in Maven’s documentation at Transitive Dependencies.

As JBoss Data Grid jar files contain all necessary dependencies to use the product, it is possible to have the same dependency included multiple times if both these jars and individual JBoss Data Grid Maven artifact(s) are specified.

To prevent this issue only one of the following should be used per Maven project:

Alternatively, if the individual components are known they may be excluded. The following example assumes that infinispan-core is being included twice; once from a defined dependency and the second time as a transient dependency.

...
<dependencies>
  <dependency>
    <groupId>org.infinispan</groupId>
    <artifactId>infinispan-embedded</artifactId>
    <version>${infinispan.version}</version>
    <scope>compile</scope>
    <exclusions>
      <exclusion>  <!-- declare the exclusion here -->
        <groupId>org.infinispan</groupId>
        <artifactId>infinispan-core</artifactId>
      </exclusion>
    </exclusions>
  </dependency>
</dependencies>
...

Red Hat JBoss Data Grid can be used in the following runtimes:

For a list of containers supported with Red Hat JBoss Data Grid, see the Release Notes or the support information here: https://access.redhat.com/articles/2435931

Red Hat JBoss Data Grid provides a set of modules for Red Hat JBoss Enterprise Application Platform 7.x. Using these modules means that JBoss Data Grid libraries do not need to be included in the user deployment. To avoid conflicts with the Infinispan modules that are already included with JBoss EAP, the JBoss Data Grid modules are placed within a separate slot and identified by the JBoss Data Grid version (major.minor).

To deploy JBoss Data Grid in JBoss EAP, add dependencies from the JBoss Data Grid module to the application’s classpath (the JBoss EAP deployer) in one of the following ways:

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
    <deployment>
        <dependencies>
            <module name="org.infinispan" slot="jdg-7.1" services="export"/>
        </dependencies>
    </deployment>
</jboss-deployment-structure>

Manifest-Version: 1.0
Dependencies: org.infinispan:jdg-7.1 services

The first line remains the same as the example. Depending on the dependency required, add one of the following to the second line of the file:

<plugin>
	<artifactId>maven-war-plugin</artifactId>
	<version>2.4</version>
	<configuration>
		<failOnMissingWebXml>false</failOnMissingWebXml>
		<archive>
			<manifestEntries>
				<Dependencies>org.infinispan:jdg-7.1 services</Dependencies>
			</manifestEntries>
		</archive>
	</configuration>
</plugin>

Red Hat JBoss Data Grid supports JBoss Enterprise Web Server in Library and Remote Client Server mode. To use JBoss Data Grid with JBoss Enterprise Web Server, bundle the JDG libraries in a web application and deploy the application on the server.

For further information on how to deploy JBoss Data Grid on JBoss Enterprise Web Server, see the Carmart Non-Transactional Quickstart in Red Hat JBoss Data Grid Quickstarts.

Red Hat JBoss Data Grid supports the WebLogic 12c application server in Library mode. The following procedure describes how to deploy web applications on a WebLogic server.

Red Hat JBoss Data Grid supports the WebLogic 12c application server in Remote Client-Server mode. The following procedure describes how to deploy web applications on a WebLogic server.

Apache Camel is an open source integration and routing system that allows transference of messages from various sources to different destinations, providing an integration framework that allows interaction with various systems using the same API, regardless of the protocol or data type. Using Camel with Red Hat JBoss Data Grid and Red Hat JBoss Fuse simplifies integration in large enterprise applications by providing a wide variety of transports and APIs that add connectivity.

JBoss Data Grid provides support for caching on Camel routes in JBoss Fuse, partially replacing Ehcache. JBoss Data Grid is supported as an embedded cache (local or clustered) or as a remote cache in a Camel route.

Red Hat JBoss Data Grid’s camel-jbossdatagrid component includes the following features:

The following camel-jbossdatagrid dependency must be added to the pom.xml file to run JBoss Data Grid with Camel:

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-jbossdatagrid</artifactId>
    <version>2.17.0.Final-redhat-2</version>
</dependency>

Camel components are the main extension point in Camel, and are associated with the name used in a URI, and act as a factory of endpoints. For example, a FileComponent is referred to in a URI as file, which creates FileEndpoints.

infinispan://hostname?[options]

A consumer listens for events from the local JBoss Data Grid cache accessible from the registry.

Camel routing is a chain of processors that move messages in the background. The following is an example of a route that retrieves a value from the cache for a specific key.

from("direct:start")
    .setHeader(InfinispanConstants.OPERATION, constant(InfinispanConstants.GET))
    .setHeader(InfinispanConstants.KEY, constant("123"))
    .to("infinispan://localhost?cacheContainer=#cacheContainer");

Routing can also be performed using XML configuration. The following example demonstrates camel-jbossdatagrid’s local-camel-producer, a camel route that uses the camel-jbossdatagrid component to send data to an embedded cache created by the local-cache module.

<camelContext id="local-producer" xmlns="http://camel.apache.org/schema/blueprint">
    <route>
        <from uri="timer://local?fixedRate=true&amp;period=5000"/>
        <setHeader headerName="CamelInfinispanKey">
            <constant>CamelTimerCounter</constant>
        </setHeader>
        <setHeader headerName="CamelInfinispanValue">
            <constant>CamelTimerCounter</constant>
        </setHeader>
        <to uri="infinispan://foo?cacheContainer=#cacheManager"/>
        <to uri="log:local-put?showAll=true"/>
    </route>
</camelContext>

The provided example requires the cacheManager to be instantiated.

The cacheManager bean for Spring XML can be instantiated as follows:

<bean id="cacheManager" class="org.infinispan.manager.DefaultCacheManager" init-method="start" destroy-method="stop">
    <constructor-arg type="java.lang.String" value="infinispan.xml"/>
</bean>

The following demonstrates how to instantiate the cacheManager bean using Blueprint XML.

<bean id="cacheManager" class="org.infinispan.manager.DefaultCacheManager" init-method="start" destroy-method="stop">
    <argument value="infinispan.xml" />
</bean>

When executing remote queries the cacheManager must be an instance of RemoteCacheManager, and an example configuration utilizing a RemoteCacheManager is found below for both Java and blueprint.xml:

from("direct:start")
    .setHeader(InfinispanConstants.OPERATION, InfinispanConstants.QUERY)
    .setHeader(InfinispanConstants.QUERY_BUILDER,
      new InfinispanQueryBuilder() {
        public Query build(QueryFactory<Query> queryFactory) {
          return queryFactory.from(User.class).having("name").like("%abc%")
                      .build();
        }
      })
    .to("infinispan://localhost?cacheContainer=#cacheManager&cacheName=remote_query_cache") ;

public class RemoteCacheManagerFactory {
    ConfigurationBuilder clientBuilder;
    public RemoteCacheManagerFactory(String hostname, int port) {
        clientBuilder = new ConfigurationBuilder();
        clientBuilder.addServer()
            .host(hostname).port(port);
    }
    public RemoteCacheManager newRemoteCacheManager() {
        return new RemoteCacheManager(clientBuilder.build());
    }
}

public class InfinispanQueryExample {
    public InfinispanQueryBuilder getBuilder() {
        return new InfinispanQueryBuilder() {
            public Query build(QueryFactory<Query> queryFactory) {
                return queryFactory.from(User.class)
                         .having("name")
                         .like("%abc%")
                         .build();
            }
        }
    }
}

<bean id=”remoteCacheManagerFactory” class=“com.jboss.datagrid.RemoteCacheManagerFactory”>
    <argument value=”localhost”/>
    <argument value="11222”/>
</bean>

<bean id=”cacheManager”
    factory-ref=”remoteCacheManagerFactory”
    factory-method=“newRemoteCacheManager”>
</bean>

<bean id="queryBuilder" class="org.example.com.InfinispanQueryExample"/>

<camelContext id="route" xmlns="http://camel.apache.org/schema/blueprint">
    <route>
        <from uri="direct:start"/>
            <setHeader headerName="CamelInfinispanOperation">
                <constant>CamelInfinispanOperationQuery</constant>
            </setHeader>
            <setHeader headerName="CamelInfinispanQueryBuilder">
                <method ref="queryBuilder" method="getBuilder"/>
            </setHeader>
        <to uri="infinispan://localhost?cacheContainer=#cacheManager&cacheName=remote_query_cache"/>
    </route>
</camelContext>

The remote_query_cache is an arbitrary name for a cache that holds the data, and the results of the query will be a list of domain objects stored as a CamelInfinispanOperationResult header.

In addition, there are the following requirements:

For more details on how to setup a RemoteCacheManager, see the Remote Querying section of the Red Hat JBoss Data Grid Infinispan Query Guide .

Custom Listeners for an embedded cache can be registered through the customListener parameter as shown below:

from("infinispan://?cacheContainer=#myCustomContainer&cacheName=customCacheName&customListener=#myCustomListener")
  .to("mock:result");

<bean id="myCustomContainer" org.infinispan.manager.DefaultCacheManager"
      init-method="start" destroy-method="stop">
      <argument value="infinispan.xml" />
</bean>

<bean id="myCustomListener" class="org.example.com.CustomListener"/>

<camelContext id="route" xmlns="http://camel.apache.org/schema/blueprint">
    <route>
        <from uri="infinispan://?cacheContainer=#myCustomContainer&cacheName=customCacheName&customListener=#myCustomListener"/>
        <to uri="mock:result"/>
    </route>
</camelContext>

The instance of myCustomListener must exist. Users are encouraged to extend the org.apache.camel.component.infinispan.embedded.InfinispanEmbeddedCustomListener and annotate the resulting class with the @Listener annotation from org.infinispan.notifications .

Custom listeners for a remote cache can be registered in the same way as an embedded cache, with the exception that sync=false must be present. For instance:

from(infinispan://?cacheContainer=#cacheManager&sync=false&customListener=#myCustomListener")
  .to(mock:result);

public class RemoteCacheManagerFactory {
    ConfigurationBuilder clientBuilder;
    public RemoteCacheManagerFactory(String hostname, int port) {
        clientBuilder = new ConfigurationBuilder();
        clientBuilder.addServer()
            .host(hostname).port(port);
    }
    public RemoteCacheManager newRemoteCacheManager() {
        return new RemoteCacheManager(clientBuilder.build());
    }
}

<bean id=”remoteCacheManagerFactory” class=“com.jboss.datagrid.RemoteCacheManagerFactory”>
    <argument value=”localhost”/>
    <argument value="11222”/>
</bean>

<bean id=”cacheManager”
    factory-ref=”remoteCacheManagerFactory”
    factory-method=“newRemoteCacheManager”>
</bean>

<bean id="myCustomListener" class="org.example.com.CustomListener"/>

<camelContext id="route" xmlns="http://camel.apache.org/schema/blueprint">
    <route>
        <from uri="infinispan://?cacheContainer=#cacheManager&sync=false&customListener=#myCustomListener"/>
        <to uri="mock:result"/>
    </route>
</camelContext>

The instance of myCustomListener must exist. Users are encouraged to extend the org.apache.camel.component.infinispan.remote.InfinispanRemoteCustomListener class and annotate the resulting class with @ClientListener; this annotation is found in org.infinispan.client.hotrod.annotation .

Remote listeners may also be associated with custom filters and converters as shown below:

@ClientListener(includeCurrentState=true, filterFactoryName = "static-filter-factory", converterFactoryName = "static-converter-factory")
  private static class MyCustomListener extends InfinispanRemoteCustomListener {
}

In order to use custom filters or converters classes annotated with @NamedFactory must be implemented. A skeleton that implements the necessary methods is shown below:

import org.infinispan.notifications.cachelistener.filter;

@NamedFactory(name = "static-converter-factory")
public static class StaticConverterFactory implements CacheEventConverterFactory {
  @Override
  public CacheEventConverter<Integer, String, CustomEvent> getConverter(Object[] params) {
    ...
  }

  static class StaticConverter implements CacheEventConverter<Integer, String, CustomEvent>, Serializable {
    @Override
    public CustomEvent convert(Integer key, String previousValue, Metadata previousMetadata,
                               String value, Metadata metadata, EventType eventType) {
      ...
    }
  }
}

@NamedFactory(name = "static-filter-factory")
public static class StaticCacheEventFilterFactory implements CacheEventFilterFactory {
  @Override
  public CacheEventFilter<Integer, String> getFilter(final Object[] params) {
    ...
  }

  static class StaticCacheEventFilter implements CacheEventFilter<Integer, String>, Serializable {
    @Override
    public boolean accept(Integer key, String previousValue, Metadata previousMetadata,
                          String value, Metadata metadata, EventType eventType) {
      ...
    }
  }
}

Custom filters and converters must be registered with the server. Registering these classes is documented in the Remote Event Listeners section of the Red Hat JBoss Data Grid Developer Guide .

Use the following instructions to run Red Hat JBoss Data Grid with Maven in Remote Client-Server mode.

Use the provided instructions to run Red Hat JBoss Data Grid with Maven in Library mode.

<dependency>
   <groupId>org.infinispan</groupId>
   <artifactId>infinispan-embedded</artifactId>
   <version>${infinispan.version}</version>
</dependency>

<dependency>
   <groupId>org.infinispan</groupId>
   <artifactId>infinispan-embedded-query</artifactId>
   <version>${infinispan.version}</version>
</dependency>

The following is a list of prerequisites to run Red Hat JBoss Data Grid in Remote Client-Server mode for the first time:

Standalone mode refers to a single instance of Red Hat JBoss Data Grid operating in local mode. In local mode, JBoss Data Grid operates as a simple single node in-memory data cache.

Run the following script to start JBoss Data Grid in standalone mode:

$JDG_HOME/bin/standalone.sh

This command starts JBoss Data Grid using the default configuration information provided in the $JDG_HOME/standalone/configuration/standalone.xml file.

Clustered mode refers to a cluster made up of two or more Red Hat JBoss Data Grid standalone instances.

Run the following script to start JBoss Data Grid in clustered mode:

$JDG_HOME/bin/standalone.sh -c clustered.xml

This command starts JBoss Data Grid using the default configuration information provided in the $JDG_HOME/standalone/configuration/clustered.xml file.

A managed domain allows multiple server instances and groups to be centrally managed from the Administration Console of the domain controller.

Run the following script to start JBoss Data Grid in a managed domain:

$JDG_HOME/bin/domain.sh

This command starts JBoss Data Grid using the default configuration information provided in the $JDG_HOME/domain/configuration/domain.xml and $JDG_HOME/domain/configuration/host.xml files.

To run Red Hat JBoss Data Grid with a custom configuration, add a configuration file to the $JDG_HOME/standalone/configuration directory.

Use the following command to specify the created custom configuration file for standalone mode:

$JDG_HOME/bin/standalone.sh -c ${FILENAME}

The -c used for this script does not allow absolute paths, therefore the specified file must be available in the $JDG_HOME/standalone/configuration directory.

If the command is run without the -c parameter, JBoss Data Grid uses the default configuration.

As a managed domain is configured with two separate files, domain.xml and host.xml by default, there are two separate flags for specifying custom configuration files.

To define the custom configuration file for the server group profiles, use the -c parameter as described above, and demonstrated in the following command:

$JDG_HOME/bin/domain.sh -c ${FILENAME}

To define the custom configuration file for the servers use the --host-config parameter, as demonstrated in the following command:

$JDG_HOME/bin/domain.sh --host-config=${FILENAME}

For production use, the Red Hat JBoss Data Grid server must be bound to a specified IP address rather than to 127.0.0.1/localhost. Use the -b parameter with the script to specify an IP address.

For standalone mode, set the IP address as follows:

$JDG_HOME/bin/standalone.sh -b ${IP_ADDRESS}

For domain mode, set the IP address for the host controller and any servers as follows:

$JDG_HOME/bin/domain.sh -b ${IP_ADDRESS}

Services send messages using channels to communicate with each other. An endpoint is a communications point for these services and is used to send and receive the messages sent through the channels. As a result, a node with no endpoints can communicate with other nodes in the same cluster, but not with clients.

The primary benefit for creating a node without endpoints in Red Hat JBoss Data Grid involves data replication.

A node without any endpoints cannot be accessed by the client directly. As a result, they are primarily used to replicate data from other nodes that can communicate with clients. The result is a node with a backup copy of the data that cannot be accessed by the client, which protects it from failure via an error sent by the client.

Red Hat JBoss Data Grid provides a sample configuration to configure a node without an endpoint:

A standard configuration, such as a standalone high availability configuration, can be changed into a configuration for a node with no endpoints by removing the endpoints subsystem from the configuration file.

Remove the XML element that begins with the following:

<subsystem xmlns="urn:infinispan:server:endpoint:8.0">

Removing the endpoints subsystem ensures endpoints are removed from the configuration and that clustering is not possible.

This part includes information about using Red Hat JBoss Data Grid in Library Mode.

This chapter is a guide to creating a new Red Hat JBoss Data Grid project. The tasks prescribed are a prerequisite for the quickstart tasks provided in Run Red Hat JBoss Data Grid in Library Mode (Single-Node Setup) and Run Red Hat JBoss Data Grid in Library Mode (Multi-Node Setup)

Set up Red Hat JBoss Data Grid by adding dependencies to your project. If you are using Maven or other build systems that support Maven dependencies, add the following to your pom.xml file, located in the Maven repository folder:

<dependency>
          <groupId>org.infinispan</groupId>
          <artifactId>infinispan-embedded</artifactId>
          <version>$VERSION</version>
</dependency>

To enable the JBoss Maven repository for your project, add a profile to your settings.xml file in $HOME/.m2/settings.xml as follows:

<profiles>

    <!-- Configure the JBoss GA Maven repository -->
    <profile>
      <id>jboss-ga-repository</id>
      <repositories>
        <repository>
          <id>jboss-ga-repository</id>
          <url>http://maven.repository.redhat.com/ga/all</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>jboss-ga-plugin-repository</id>
          <url>http://maven.repository.redhat.com/ga/all</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
        </pluginRepository>
      </pluginRepositories>
    </profile>
    <!-- Configure the JBoss Early Access Maven repository -->
    <profile>
      <id>jboss-earlyaccess-repository</id>
      <repositories>
        <repository>
          <id>jboss-earlyaccess-repository</id>
          <url>http://maven.repository.redhat.com/earlyaccess/all/</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>jboss-earlyaccess-plugin-repository</id>
          <url>http://maven.repository.redhat.com/earlyaccess/all/</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
        </pluginRepository>
      </pluginRepositories>
    </profile>

  </profiles>

<!-- Add active profiles information here -->

Enable the profile by ensuring the following is included in the settings.xml file:

  <activeProfiles>
    <!-- Optionally, make the repositories active by default -->
    <activeProfile>jboss-ga-repository</activeProfile>
    <activeProfile>jboss-earlyaccess-repository</activeProfile>
  </activeProfiles>

If you are using a build system that does not support declarative dependency management, ensure all used libraries, such as infinispan-embedded, are found on the build classpath.

Red Hat JBoss Data Grid offers an easy to use form of clustering using JGroups as the network transport. As a result, JGroups manages the initial operations required to form a cluster for JBoss Data Grid.

All caches created from a single CacheManager share the same JGroups channel by default. This JGroups channel is used to multiplex replication/distribution messages.

In the following example, all three caches used the same JGroups channel:

EmbeddedCacheManager cm = $LOCATION
Cache<Object, Object> cache1 = cm.getCache("replSyncCache");
Cache<Object, Object> cache2 = cm.getCache("replAsyncCache");
Cache<Object, Object> cache3 = cm.getCache("invalidationSyncCache");

Substitute $LOCATION with the CacheManager’s location.

An example of a clustered setup is found in the Hello World Quickstart.

Red Hat JBoss Data Grid library applications (in the form of WAR or EAR files) can be deployed within JBoss Enterprise Application Server 6 (or better) and then monitored using JBoss Operations Network.

The following are prerequisites to monitor a Red Hat JBoss Data Grid library application in JBoss Enterprise Application Platform:

Ensure that all requirements outlined as prerequisites are met. Follow the listed steps to monitor Red Hat JBoss Data Grid applications in JBoss Enterprise Application Platform using JBoss Operations Network or RHQ.

A Cache Manager is the primary mechanism to retrieve a cache instance in Red Hat JBoss Data Grid, and is a starting point for using the cache.

In JBoss Data Grid, a cache manager is useful because:

Red Hat JBoss Data Grid offers the following Cache Managers:

Hello World is a simple quickstart that illustrates how to store and retrieve data from a cache using Red Hat JBoss Data Grid. For this quickstart, users can access the cache in two ways:

All libraries (JAR files) bundles with the application are deployed to JBoss Enterprise Application Platform 7.x. JBoss Data Grid’s Library mode only allows local access to a single node in a distributed cluster. This mode also allows the application to access the data grid functionality within a virtual machine in the target container.

The prerequisites for this quickstart are as follows:

Before deploying the Hello World quickstart, start two instances of your application server (JBoss Enterprise Application Platform 7.x).

Before building and deploying the quickstart, ensure that all the listed prerequisites are met and that the two application server instances are running (see for details).

The Hello World quickstart application runs on the following URLs:

Use the following instructions to test that cache entries are replicating from the first server instance to the second as desired.

As the results of the last step show, all the data added at each server has been replicated to the other server.

http://localhost:8080/jboss-helloworld-jdg/TestServletPut

http://localhost:8180/jboss-helloworld-jdg/TestServletGet

Use the following procedure to remove the Hello World application:

The following procedures contain instructions to remove Red Hat JBoss Data Grid from your Linux system.

The following procedures contain instructions to remove Red Hat JBoss Data Grid from your Microsoft Windows system.