Boost your infrastructure with Coherence into the Cloud

Authors: Nino Guarnacci & Francesco Scarano,  at this URL could be found the original article:

Thinking about the enterprise cloud, come to mind many possible configurations and new opportunities in enterprise environments. Various customers needs that serve as guides to this new trend are often very different, but almost always united by two main objectives:

  • Elasticity of infrastructure both Hardware and Software
  • Investments related to the progressive needs of the current infrastructure

Characteristics of innovation and economy.

A concrete use case that I worked on recently demanded the fulfillment of two basic requirements of economy and innovation.
The client had the need to manage a variety of data cache, which can process complex queries and parallel computational operations, maintaining the caches in a consistent state on different server instances, on which the application was installed.
In addition, the customer was looking for a solution that would allow him to manage the likely situations in load peak during certain times of the year.
For this reason, the customer requires a replication site, on which convey part of the requests during periods of peak; the desire was, however, to prevent the immobilization of investments in owned hardware-software architectures; so, to respond to this need, it was requested to seek a solution based on Cloud technologies and architectures already offered by the market.

Coherence can already now address the requirements of large cache between different nodes in the cluster, providing further technology to search and parallel computing, with the simultaneous use of all hardware infrastructure resources. Moreover, thanks to the functionality of "Push Replication", which can replicate and update the information contained in the cache, even to a site hosted in the cloud, it is satisfied the need to make resilient infrastructure that can be based also on nodes temporarily housed in the Cloud architectures.

There are different types of configurations that can be realized using the functionality "Push-Replication" of Coherence.

Configurations can be either:

  • Active - Passive
    •  Hub and Spoke
  • Active - Active
    • Multi Master
    • Centralized Replication

Whereas the architecture of this particular project consists of two sites (Site 1 and Site Cloud), between which only Site 1 is enabled to write into the cache, it was decided to adopt an Active-Passive Configuration type (Hub and Spoke). If, however, the requirement should change over time, it will be particularly easy to change this configuration in an Active-Active configuration type.

Although very simple, the small sample in this post, inspired by the specific project is effective, to better understand the features and capabilities of Coherence and its configurations.

Let's create two distinct coherence cluster, located at miles apart, on two different domain contexts, one of them "hosted" at home (on-premise) and the other one hosted by any cloud provider on the network (or just the same laptop to test it :)). These two clusters, which we call Site 1 and Site Cloud, will contain the necessary information, so a simple client can insert data only into the Site 1. On both sites will be subscribed a listener, who listens to the variations of specific objects within the various caches.

To implement these features, you need 4 simple classes:

Represents the POJO class that will be inserted into the cache, and fulfills the task of containing useful information about the hypothetical links navigation

Represents a link simulator, which has the task of randomly creating objects of type CachedResponse that will be added into the caches

Represents the model of our example, because it is responsible for receiving instructions from the controller and performing basic operations against the cache, such as insert, delete, update, listening, objects within the cache

It is our controller, which give commands to be executed within the cache of the two Sites

So, summarily, we execute the java class "Shell", asking it to put into the cache 100 objects of type "CachedResponse" through the java class "CacheCommands", then the simulator "ResponseSimulatorHelper" will randomly create new instances of objects "CachedResponse ". Finally, the Shell class will listen to for events occurring within the cache on the Site Cloud, while insertions and deletions are performed on Site 1.

Now, we realize the two configurations of two respective sites / cluster: Site 1 and Site Cloud.

For the Site 1 we define a cache of type "distributed" with features of "read and write", using the cache class store for the "push replication", a functionality offered by the project "incubator" of Oracle Coherence.

For the "Site Cloud" we expect even the definition of “distributed” cache type with tcp proxy feature enabled, so it can receive updates from Site 1.

For two clients "Shell" which will connect respectively to the two clusters we have provided two easy access configurations.

Now, we just have to get everything and run our tests.

To start at least one "storage" node (which holds the data) for the "Cloud Site", we can run the standard class  provided OOTB by Oracle Coherence

with the following parameters and values:

To start at least one "storage" node (which holds the data) for the "Site 1", we can perform again the standard class provided by Coherence

with the following parameters and values:

Then, we start the first client "Shell" for the "Cloud Site", launching the java class


using these parameters and values:


Finally, we start the second client "Shell" for the "Site 1", re-launching a new instance of class 


using  the following parameters and values:


 And now, let’s execute some tests to validate and better understand our configuration.

The purpose of this test is to load the objects into the "Site 1" cache and seeing how many objects are cached on the "Site Cloud".

  • Within the "Shell" launched with parameters to access the "Site 1", let’s write and run the command:
    • load test/100
  • Within the "Shell" launched with parameters to access the "Site Cloud" let’s write and run the command:
    • size passive-cache

Expected result

If all is OK, the first "Shell" has uploaded 100 objects into a cache named "test"; consequently the "push-replication" functionality has updated the "Site Cloud" by sending the 100 objects to the second cluster where they will have been posted into a respective cache, which we named "passive-cache".

The purpose of this test is to listen to deleting and adding events happening on the "Site 1" and that are replicated within the cache on "Cloud Site".

  • In the "Shell" launched with parameters to access the "Site Cloud" let’s write and run the command:
    • listen passive-cache/name like '%'
  • or
    • a "cohql" query, with your preferred parameters
  • In the "Shell" launched with parameters to access the "Site 1" let’s write and run the following commands:
    • load test/10
    • load test2/20
    • delete test/50

Expected result

If all is OK, the "Shell" to Site Cloud let us to listen to all the add and delete events within the cache "cache-passive", whose objects satisfy the query condition "name like '%' " (ie, every objects in the cache; you could change the tests and create different queries).
Through the Shell to "Site 1" we launched the commands to add and to delete objects on different caches (test and test2).
With the "Shell" running on "Site Cloud" we got the evidence (displayed or printed, or in a log file) that its cache has been filled with events and related objects generated by commands executed from the" Shell "on" Site 1 ", thanks to "push-replication" feature. 

Other tests can be performed, such as, for example, the subscription to the events on the "Site 1" too, using different "cohql" queries, changing the cache configuration,  to effectively demonstrate both the potentiality and  the versatility produced by these different configurations, even in the cloud, as in our case.

More information on how to configure Coherence "Push Replication" can be found in the Oracle Coherence Incubator project documentation at the following link:

More information on Oracle Coherence "In Memory Data Grid" can be found at the following link:

To download and execute the whole sources and configurations of the example explained in the above post,  click here to download them; After download the last available version of the Push-Replication Pattern library implementation from the Oracle Coherence Incubator site, and download also the related and required version of Oracle Coherence.

For simplicity the required .jarS to execute the example (that can be found into the Push-Replication-Pattern  download and Coherence Distribution download) are:

  • activemq-core-5.3.1.jar
  • activemq-protobuf-1.0.jar
  • aopalliance-1.0.jar
  • coherence-commandpattern-
  • coherence-common-
  • coherence-eventdistributionpattern-
  • coherence-functorpattern-
  • coherence-messagingpattern-
  • coherence-processingpattern-
  • coherence-pushreplicationpattern-
  • coherence-rest.jar
  • coherence.jar
  • commons-logging-1.1.jar
  • commons-logging-api-1.1.jar
  • commons-net-2.0.jar
  • geronimo-j2ee-management_1.0_spec-1.0.jar
  • geronimo-jms_1.1_spec-1.1.1.jar
  • http.jar
  • jackson-all-1.8.1.jar
  • je.jar
  • jersey-core-1.8.jar
  • jersey-json-1.8.jar
  • jersey-server-1.8.jar
  • jl1.0.jar
  • kahadb-5.3.1.jar
  • miglayout-3.6.3.jar
  • org.osgi.core-4.1.0.jar
  • spring-beans-2.5.6.jar
  • spring-context-2.5.6.jar
  • spring-core-2.5.6.jar
  • spring-osgi-core-1.2.1.jar
  • spring-osgi-io-1.2.1.jar

At this URL could be found the original article:

Authors: Nino Guarnacci & Francesco Scarano


Post a Comment:
  • HTML Syntax: NOT allowed

.. useful blog on java and middleware technologies.


« December 2016