Dynamic cache instantiation parameters

Question

I need to offer "customers" of my cloud/cache services the ability to specify some of the properties they want in caches they create.
I am operating with the restriction that we cannot restart cluster members just for the purpose of rereading the cache-config.xml
files. I am using Coherence Grid 3.5.2 and java.
By way of example, let me refer to the coherence examples provided at
[http://wiki.tangosol.com/display/COH35UG/Examples|http://wiki.tangosol.com/display/COH35UG/Examples]
In 'examples-cache-config.xml' from that set of examples is the following scheme:
<distributed-scheme>
<scheme-name>ExamplesPartitionedPofScheme</scheme-name>
<service-name>PartitionedPofCache</service-name>
<serializer>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
<init-params>
<init-param>
<param-type>String</param-type>
<param-value>examples-pof-config.xml</param-value>
</init-param>
</init-params>
</serializer>
<backing-map-scheme>
<local-scheme>
<high-units>250M</high-units>
<unit-calculator>binary</unit-calculator>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
What I want to do is create, at runtime, a relatively arbitrary set of caches
that will have differing values for <high-units> and related parameters.
Presumably I need to code my own calls to the LocalCache() constructor.
That would also let me dynamically select eviction policies and unit calculators
(via the LocalCache's implementation of ConfigurableCacheMap's setEvictionPolicy() and setUnitCalculator() methods).
Can someone show me how to do this with the Coherence examples?
Ultimately I need to be able to specify, for all maps on all distributed caches I support for my "customers",
the low and high water marks, eviction policies, and perhaps some other properties, and ensure that all cluster members
participate in identical handling of the resulting named cache to the extent that they're servicing keys for that cache.
I tried taking my own application <distributed-scheme> definitions and constructing various
frontMap, backMap, NearCache, NamedCache, and related goodies to assemble the cache on the fly,
and I'm in /way/ over my head. I haven't found any online documentation on how to assemble
things like ObserveableSplittingBackingMap objects into a hierarchy of Coherence objects.
The logical hierarchy of Cluster->Member->Service->NamedCache elements doesn't seem to map
well to code for assembling each of those pieces.
Also note: the Coherence 3.5.2 docs state that <lh-file-manager> maps to com.tangosol.io.lh.LHBinaryStoreManager class,
but there is no such class documented in the javadocs (though I see that class in the coherence.jar file).
Thanks.

Answer 1

So all I can really tweak are the high-units, low-units, and any other RW-flagged attributes of the CacheMBean types.Yes, this is correct in general.
When I call these MBean interfaces, it has to be after the cache is created, and will affect the named cache wherever it lives
on the cluster w.r.t. partition presence, LocalCache frontmaps, etc?These high/low unit modifications must be performed on each individual MBean representing the backing map in each storage node. The same goes for any nodes that are using near caches.
No way to make cache eviction policy dynamic except to perhaps implement my own custom eviction class and have that
observe some attribute I bind somewhere that's specific to a cache instance?I believe you can change the eviction policy at runtime (LRU vs LFU, etc) - if you need more control over what gets evicted then you should consider a custom eviction policy.
I'm not very familiar with JMX. To do the high-unit low-unit tweaking must I now enable JMX where I didn't before?
I noticed that for my testing I needed to specify -Dcom.sun.management.jmxremote and one or both of -Dtangosol.coherence.management=all -Dtangosol.coherence.management.remote=true.
Is there a way to set high/low unit values if I'm not enabling JMX? Do I suffer any performance penalties if I enable JMX?Most of our customers in production run with JMX as it allows for statistics gathering and diagnostics of the cluster at runtime. There is no overhead in gathering the stats as this happens in the background anyway, and there is little overhead in enabling the gathering of these statistics and viewing via an MBeanServer.
JMX is the simplest way (and the supported method) of modifying high units. If you have to do it using code, you can execute the following in the storage node to grab the backing map and modify high units. Note that this technique may not work with future versions of Coherence:
String sCacheService = "DistributedCache";
String sCacheName    = "test-cache";
// ensures that the cache service is running
CacheFactory.getCache(sCacheName);
// grab the backing map
CacheService service  = (CacheService) CacheFactory.getCluster().getService(sCacheService);
LocalCache backingMap = (LocalCache)((DefaultConfigurableCacheFactory.Manager)
        service.getBackingMapManager()).getBackingMap(sCacheName);
// modify high units
backingMap.setHighUnits(1000);Thanks,
Patrick