Hmm, thats tough. Did you consider the client/server module, so that your client app can sit outside of the Infinispan cluster?
So you mean using Hot Rod? I'm new to infinispan - so I will have a look at it.
I know for example Oracle Coherence supports this feature just by setting an argument (...localstorage=false). In this case the node is a full member of the cluster, but without storing data (e.g. to disable storage on an application server) Is such a feature planned for infispan?
1 of 1 people found this helpful
In a sense we do have such a feature. It's called the RemoteCache. It is the Java based Hot Rod client and it speaks the Hot Rod wire protocol to the storage nodes. Have a look at the wiki under Hot Rod clients, there are examples, etc.
I agree with the fact that Infinispan support client/server behavior through the RemoteCache but I think that this feature can be very useful for some scenarios with embedded caches.
For example, we are building a cluster that need to be configure and run within a jee container (we cannot launch any other process because we do not manage the OS, we can only access the jee container admin console). So, for us, the embedded cache is our only option: We can create a cluster without lauching an external processes to manage the storage.
Now, with this embedded cluster running, other applications needs to access the data grid but they should not be part of the storage (a.k.a. a client). How can we access the already defined cluster (with embedded caches only) from another JVM without joining the cluster as a member of the storage?
We are experimenting with the Key Affinity Service to identify the nodes and then we are trying to use the Group API to force all the data to be stored in some nodes (excluding the 'clients' node), but we are struglying with topology changes issues.
IMHO it should be great to exclude a node from the hash space when deciding where to storage a key. What do you think?
This sounds familiar, i.e. your experiments with Key Affinity Service and the Grouping API, see my earlier discussion: Data Location and the Grouping API
And your "struggles" may relate to these issues raised sometime ago by a colleague of mine?
Thanks for sharing those links ... is always good to know that we're not the only ones trying to do this.
Regarding the topology issues, we are working over the POC right now and the results are very unstables. I'll share my findings when I've got a more educated statement.