CODEWITHSUNDEEP
javaehcacheconsistency
Jason
Jason

Reputation: 1431

EHCache: Verify Cache Equivilance across JVM's

I have a working proof of concept for EHcaches' JMS Replication topology with Websphere MQ.

To explain a bit about how it works, I have 2 JVM's running. When JVM1 calls the EHCache 'put' method, an element is put into cache, which is then replicated in JVM2 (which is accomplished through EHCache configuration).

According to EhCache's documentation the JMS Replication topology is considered as "weak consistency", meaning it might have problems with each JVM's Cache node being up to date with the rest.

Does anyone have any idea how I can compare two JVM's (cache nodes) to ensure they contain equivilant Cache objects and all cache elements within?

Upvotes: 4

Views: 395

Answers (1)

Renat Gilmanov
Renat Gilmanov

Reputation: 17895

It does look like you've defined the problem in a pretty complex way. Let's try to simplify a bit:

  • First of all, you have something like a distributed Map, so there is no need to compare JVMs or cache nodes
  • Secondly, you are designing a way to verify/test your setup, so you can use predefined data

Let's say we have two cache nodes and some Replication magic (provided by Ehcache in your case):

enter image description here

We can also generate some test data (a set of key:value) pairs. So the simplest way to test Replication magic will be to import our data into the Node 1 and design a very simple tool to monitor the 'Node 2'.

Please note, you have test data predefined, so you know keys and can scan Node 2 periodically trying to get associated values. It would be a good idea to collect additional info like delays, errors, etc in order simplify further analysis.

Solving similar problem I used handy visualization to simplify analysis even more. Here is the initial design (entity size was also tracked, because there might be some correlations):

enter image description here

Such approach simplifies monitoring a lot, moreover, it allows to tune the system, because there is relevant feedback always available.

I did create a mockup implementation to show how it might look like. Basically, test logic can be described as follows:

  1. A tool imports data into the Node 1
  2. Replication logic start to replicate data
  3. For every known key the tool tries to get a value from the Node 2.
  4. Tool performs scan periodically until all data is available

In run-time it might look like the following (please do not forget mockup system is used):

enter image description here

I have some reasonable limit defined because there is actually no magic behind replication process, so it might take some time.

Thoroughly designed test data will reveal lots of hidden secrets.

Upvotes: 3

Related Questions