Near Cache JMX Monitoring

Hi,
Can the JMX monitoring capabilities of Coherence be used to monitor the hit-rate of a near cache, i.e. by adding the JMX command line options to the extend client - to determine how effective it is?
Thanks

Hi dxfelcey,
You can get to the NearCache statistics by querying CacheMBean(s) with key attribute "tier=front". For example, the following query will return you a set of ObjectNames for all MBeans representing NearCache called "test" instances across the cluster:
MBeanServer mbs=MBeanHelper.findMBeanServer();
Set setNames = mbs.queryNames(new ObjectName("type=Cache,name=test,tier=front,*"), null);For more information please see the Registry Javadoc here:
http://download.oracle.com/otn_hosted_doc/coherence/330/com/tangosol/net/management/Registry.html
and the Coherence Wiki page here:
http://wiki.tangosol.com/display/COH33UG/Managing+Coherence+using+JMX
Regards,
Gene

Similar Messages

JMX monitoring front Coherence cache running on IBM WebSphere

I have a question regarding JMX monitoring a Coherence front cache running in a IBM WebSphere v6.1 JVM (1.5).
My setup is that I have three Coherence nodes (back cache) each running 10 JVMs each. Via JMX all these 30 JVMs are setup to be monitored from one of the 30 JVMs which is configured to be the JmxServer for the other 29 instances. The other 29 JVMs set -Dtangosol.coherence.management.remote=true at startup to indicate that their MBean tree will be managed centrally. This works fine but when I try to extend this to also be able to manage the front cache (running on WebSphere on a separate node in the tier above) by adding the same flag (-Dtangosol.coherence.management.remote=true) it does not appear in the MBean tree as the other 30 Coherence cache (Sun) JVMs do.
Are there other things I have to consider to get this working? There are no firewalls in between the nodes so that is not the problem. How much of IBM WebSpheres (non-standard) JMX-functionality is required to get this to work?
/Jonas

How is the WebSphere node connected to the cluster? Is it using TCMP? Extend?
Local, Distributed, Replicated, Near, Overflow, External and Optimistic cache statistics appear in the Coherence JMX server. However, near and local caches created on extend nodes do not appear. Therefore the -Dtangosol.coherence.management.remote=true on an Extend client will not register the near or local caches.
Thanks,
Everett

Update to near cache value is not reflected in the other near cache

Hi,
I have a cluster of two weblogic servers running within them tangosol cache. I also have two seperate tangosol servers running on the same two servers.
When I make an update on the tangosol cache on one of the weblogic application, unfortunately the update is not picked up by the other weblogic application tangosol cache.
What do I need to do so that all updates are available in all the tangosol cache?
example below:
initial:
server1: weblogic tangosol near cache, key = "One", Value = null
server2: weblogic tangosol near cache, key = "One", Value = null
update on server1;
server1: weblogic tangosol near cache, key = "One", Value = "New York"
server2: weblogic tangosol near cache, key = "One", Value = null <- still null (?)
Why is the value on server2 not updated also?
Thanks.
The tangosol configuration is a near distributed cache. The xml is below. Thanks.
<?xml version="1.0"?>
<!DOCTYPE cache-config SYSTEM "cache-config.dtd">
<cache-config>
<caching-scheme-mapping>

<cache-mapping>
<cache-name>*</cache-name>
<scheme-name>default-near</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>

<near-scheme>
<scheme-name>default-near</scheme-name>
<front-scheme>
<local-scheme>
<scheme-ref>default-eviction</scheme-ref>
</local-scheme>
</front-scheme>
<back-scheme>
<distributed-scheme>
<scheme-ref>default-distributed</scheme-ref>
</distributed-scheme>
</back-scheme>

<invalidation-strategy>auto</invalidation-strategy>

<autostart>false</autostart>
</near-scheme>

<distributed-scheme>
<scheme-name>default-distributed</scheme-name>
<service-name>DistributedCache</service-name>
<backing-map-scheme>
<class-scheme>
<scheme-ref>default-backing-map</scheme-ref>
</class-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

<class-scheme>
<scheme-name>default-backing-map</scheme-name>
<class-name>com.tangosol.util.SafeHashMap</class-name>
<init-params></init-params>
</class-scheme>

<local-scheme>
<scheme-name>default-eviction</scheme-name>
<eviction-policy>HYBRID</eviction-policy>
<high-units>100000</high-units>
<low-units>0</low-units>
<expiry-delay>0</expiry-delay>
<flush-delay>0</flush-delay>
<cachestore-scheme></cachestore-scheme>
</local-scheme>
</caching-schemes>
</cache-config>

We can certainly set up a call to discuss what you are seeing. Please email [email protected] with your phone number and other information to set up the call.
The more information that you can provide in advance (on the forum or by email), the better. For example, send your configuration settings (cache configuration, cluster configuration) files.
Peace.

Read-Through Caching with expiry-delay and near cache (front scheme)

We are experiencing a problem with our custom CacheLoader and near cache together with expiry-delay on the backing map scheme.
I was under the assumption that it was possible to have an expiry-delay configured on the backing-scheme and that the near cache object was evicted when backing object was evicted. But according to our tests we have to put an expiry-delay on the front scheme too.
Is my assumption correct that there will not be automatic eviction on the near cache (front scheme)?
With this config, near cache is never cleared:
             <near-scheme>
                  <scheme-name>config-part</scheme-name>
                  <front-scheme>
                        <local-scheme />
                  </front-scheme>
                  <back-scheme>
                        <distributed-scheme>
                              <scheme-ref>config-part-distributed</scheme-ref>
                        </distributed-scheme>
                  </back-scheme>
            <autostart>true</autostart>
            </near-scheme>
            <distributed-scheme>
                  <scheme-name>config-part-distributed</scheme-name>
                  <service-name>partDistributedCacheService</service-name>
                  <thread-count>10</thread-count>
                  <backing-map-scheme>
                        <read-write-backing-map-scheme>
                              <read-only>true</read-only>
                              <scheme-name>partStatusScheme</scheme-name>
                              <internal-cache-scheme>
                                    <local-scheme>
                                          <scheme-name>part-eviction</scheme-name>
                                          <expiry-delay>30s</expiry-delay>
                                    </local-scheme>
                              </internal-cache-scheme>
                              <cachestore-scheme>
                                    <class-scheme>
                                          <class-name>net.jakeri.test.PingCacheLoader</class-name>
                                    </class-scheme>
                              </cachestore-scheme>
                              <refresh-ahead-factor>0.5</refresh-ahead-factor>
                        </read-write-backing-map-scheme>
                  </backing-map-scheme>
                  <autostart>true</autostart>
                  <local-storage system-property="tangosol.coherence.config.distributed.localstorage">true</local-storage>
            </distributed-scheme>With this config (added expiry-delay on front-scheme), near cache gets cleared.
        <near-scheme>
                  <scheme-name>config-part</scheme-name>
                  <front-scheme>
                        <local-scheme>
                             <expiry-delay>15s</expiry-delay>
                        </local-scheme>
                  </front-scheme>
                  <back-scheme>
                        <distributed-scheme>
                              <scheme-ref>config-part-distributed</scheme-ref>
                        </distributed-scheme>
                  </back-scheme>
            <autostart>true</autostart>
            </near-scheme>
            <distributed-scheme>
                  <scheme-name>config-part-distributed</scheme-name>
                  <service-name>partDistributedCacheService</service-name>
                  <thread-count>10</thread-count>
                  <backing-map-scheme>
                        <read-write-backing-map-scheme>
                              <read-only>true</read-only>
                              <scheme-name>partStatusScheme</scheme-name>
                              <internal-cache-scheme>
                                    <local-scheme>
                                          <scheme-name>part-eviction</scheme-name>
                                          <expiry-delay>30s</expiry-delay>
                                    </local-scheme>
                              </internal-cache-scheme>
                              <cachestore-scheme>
                                    <class-scheme>
                                          <class-name>net.jakeri.test.PingCacheLoader</class-name>
                                    </class-scheme>
                              </cachestore-scheme>
                              <refresh-ahead-factor>0.5</refresh-ahead-factor>
                        </read-write-backing-map-scheme>
                  </backing-map-scheme>
                  <autostart>true</autostart>
                  <local-storage system-property="tangosol.coherence.config.distributed.localstorage">true</local-storage>
            </distributed-scheme>

Hi Jakkke,
The Near Cache scheme allows to have configurable levels of cache coherency from the most basic expiry based cache to invalidation based cache to data versioning cache depending on the coherency requirements. The Near Cache is commonly used to achieve the performance of replicated cache without losing the scalability aspects of replicated cache and this is achieved by having a subset of data (based on MRU or MFU) in the <front-scheme> of the near cache and the complete set of data in the <back-scheme> of near cache. The <back-scheme> updates can automatically trigger events to invalidate the entries in the <front-scheme> based on the invalidation strategy (present, all, none, auto) configured for the near cache.
If you want to expire the entries in the <front-scheme> and <back-scheme>, you need to specify an expiry-delay on both the schemes as mentioned by you in the last example. Now if you are expiring the items in the <back-scheme> for the reason that they get loaded again from the cache-store but the <front-scheme> keys remain same (only the values should be refreshed from the cache store) then you need not set the expiry-delay on the <front-scheme> rather mention the invalidation-strategy as present. But if you want to have a different set of entries in <front-scheme> after a specified expiry delay then you need to mention it in the <front-scheme> configuration.
The near cache has the capability to keep front scheme and back scheme data in sync but the expiry of entries is not synced. Always, front-scheme is a subset of back-scheme.
Hope this helps!
Cheers,
NJ

How can I get a count of objects in the near cache? (Extend client)

Hi,
I'm trying to figure out how to get the count of objects in my near cache (from c++ client). Knowing the size of the near cache is a key factor when optimizing configurations for performance.
However if I call size() on the cache handle I get the count of objects in the cache (ie the cluster). How can I get a count of objects in the near cache?
Thanks
Rich Carless

H Rich,
It may not be ideal, but I think you may be able to infer the size by using the HeapAnalyzer (http://download.oracle.com/docs/cd/E15357_01/coh.360/e15728/classcoherence_1_1lang_1_1_heap_analyzer.html) facility, specifically the "class" based HeapAnalyzer. Its Snapshot representation http://download.oracle.com/docs/cd/E15357_01/coh.360/e15728/classcoherence_1_1lang_1_1_class_based_heap_analyzer_1_1_snapshot.html provides a mapping between class name and ClassStats (http://download.oracle.com/docs/cd/E15357_01/coh.360/e15728/classcoherence_1_1lang_1_1_class_based_heap_analyzer_1_1_class_stats.html) which provides information on how many instances of a given class type are in memory. Note the reported counts are process wide but if your key or value type are distinct you may be able to infer your answer. I realize this is rather complex, my only other suggestion would be to just make some guesses on size and see how they effect performance.
Mark
Oracle Coherence

Can off JVM heap Memory used in the Near-Cache front-tier

I had tried to config a near-Cache used nio-manager(off JVM heap) in the Front-tier.
<near-scheme>
      <scheme-name>CohApp-near</scheme-name>
      <front-scheme>
        <external-scheme>
        </external-scheme>
      </front-scheme>
      <back-scheme>
        <distributed-scheme>
          <scheme-ref>CohApp-distributed</scheme-ref>
        </distributed-scheme>
      </back-scheme>
      <invalidation-strategy>auto</invalidation-strategy>
      <autostart>true</autostart>
    </near-scheme>
when start 'com.tangosol.net.DefaultCacheServer' for this config, error as:
Oracle Coherence Version 3.7.1.0 Build 27797
Enterprise Edition: Development mode
Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.
2014-03-30 16:34:17.518/1.201 Oracle Coherence EE 3.7.1.0 <Error> (thread=main,
member=n/a): Error org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invali
d content was found starting with element 'external-scheme'. One of '{"http://xm
lns.oracle.com/coherence/coherence-cache-config":local-scheme, "http://xmlns.ora
cle.com/coherence/coherence-cache-config":class-scheme}' is expected. - line 92
Exception in thread "main" (Wrapped: Failed to load the factory) (Wrapped: Missi
ng or inaccessible constructor "com.tangosol.net.DefaultConfigurableCacheFactory
(String)"
<configurable-cache-factory-config>
<class-name>com.tangosol.net.DefaultConfigurableCacheFactory</class-name>
<init-params>
    <init-param>
      <param-type>java.lang.String</param-type>
      <param-value>coherence-cache-config.xml</param-value>
    </init-param>
</init-params>
</configurable-cache-factory-config>) java.lang.reflect.InvocationTargetExceptio
n
        at com.tangosol.util.Base.ensureRuntimeException(Base.java:288)
        at com.tangosol.net.ScopedCacheFactoryBuilder.getDefaultFactory(ScopedCa
cheFactoryBuilder.java:311)
        at com.tangosol.net.DefaultCacheFactoryBuilder.getSingletonFactory(Defau
ltCacheFactoryBuilder.java:48)
        at com.tangosol.net.DefaultCacheFactoryBuilder.getFactory(DefaultCacheFa
ctoryBuilder.java:121)
        at com.tangosol.net.ScopedCacheFactoryBuilder.getConfigurableCacheFactor
y(ScopedCacheFactoryBuilder.java:112)
        at com.tangosol.net.CacheFactory.getConfigurableCacheFactory(CacheFactor
y.java:126)
        at com.tangosol.net.DefaultCacheServer.getDefaultConfigurableCacheFactor
y(DefaultCacheServer.java:364)
        at com.tangosol.net.DefaultCacheServer.main(DefaultCacheServer.java:197)
Caused by: (Wrapped: Missing or inaccessible constructor "com.tangosol.net.Defau
ltConfigurableCacheFactory(String)"
<configurable-cache-factory-config>
<class-name>com.tangosol.net.DefaultConfigurableCacheFactory</class-name>
<init-params>
    <init-param>
      <param-type>java.lang.String</param-type>
      <param-value>coherence-cache-config.xml</param-value>
    </init-param>
</init-params>
</configurable-cache-factory-config>) java.lang.reflect.InvocationTargetExceptio
n
        at com.tangosol.util.Base.ensureRuntimeException(Base.java:288)
        at com.tangosol.run.xml.XmlHelper.createInstance(XmlHelper.java:2652)
        at com.tangosol.run.xml.XmlHelper.createInstance(XmlHelper.java:2536)
        at com.tangosol.net.ScopedCacheFactoryBuilder.getDefaultFactory(ScopedCa
cheFactoryBuilder.java:273)
        ... 6 more
Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct
orAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC
onstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at com.tangosol.util.ClassHelper.newInstance(ClassHelper.java:694)
        at com.tangosol.run.xml.XmlHelper.createInstance(XmlHelper.java:2611)
        ... 8 more
Caused by: (Wrapped: Failed to load cache configuration: coherence-cache-config.
xml) (Wrapped) java.io.IOException: Exception occurred during schema validation:
cvc-complex-type.2.4.a: Invalid content was found starting with element 'externa
l-scheme'. One of '{"http://xmlns.oracle.com/coherence/coherence-cache-config":l
ocal-scheme, "http://xmlns.oracle.com/coherence/coherence-cache-config":class-sc
heme}' is expected.
        at com.tangosol.util.Base.ensureRuntimeException(Base.java:288)
        at com.tangosol.run.xml.XmlHelper.loadResourceInternal(XmlHelper.java:34
1)
        at com.tangosol.run.xml.XmlHelper.loadFileOrResource(XmlHelper.java:283)
        at com.tangosol.net.DefaultConfigurableCacheFactory.loadConfig(DefaultCo
nfigurableCacheFactory.java:439)
        at com.tangosol.net.DefaultConfigurableCacheFactory.loadConfig(DefaultCo
nfigurableCacheFactory.java:425)
        at com.tangosol.net.DefaultConfigurableCacheFactory.<init>(DefaultConfig
urableCacheFactory.java:155)
        ... 14 more
Caused by: (Wrapped) java.io.IOException: Exception occurred during schema valid
ation:
cvc-complex-type.2.4.a: Invalid content was found starting with element 'externa
l-scheme'. One of '{"http://xmlns.oracle.com/coherence/coherence-cache-config":l
ocal-scheme, "http://xmlns.oracle.com/coherence/coherence-cache-config":class-sc
heme}' is expected.
        at com.tangosol.run.xml.XmlHelper.loadXml(XmlHelper.java:122)
        at com.tangosol.run.xml.XmlHelper.loadXml(XmlHelper.java:157)
        at com.tangosol.run.xml.XmlHelper.loadResourceInternal(XmlHelper.java:32
2)
        ... 18 more
Caused by: java.io.IOException: Exception occurred during schema validation:
cvc-complex-type.2.4.a: Invalid content was found starting with element 'externa
l-scheme'. One of '{"http://xmlns.oracle.com/coherence/coherence-cache-config":l
ocal-scheme, "http://xmlns.oracle.com/coherence/coherence-cache-config":class-sc
heme}' is expected.
        at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:212)
        at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:93)
        at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:162)
        at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:115)
        at com.tangosol.run.xml.XmlHelper.loadXml(XmlHelper.java:118)
        ... 20 more
Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid conten
t was found starting with element 'external-scheme'. One of '{"http://xmlns.orac
le.com/coherence/coherence-cache-config":local-scheme, "http://xmlns.oracle.com/
coherence/coherence-cache-config":class-scheme}' is expected.
        at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAX
ParseException(ErrorHandlerWrapper.java:195)
        at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(Err
orHandlerWrapper.java:131)
        at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(
XMLErrorReporter.java:384)
        at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(
XMLErrorReporter.java:318)
        at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErro
rReporter.reportError(XMLSchemaValidator.java:417)
        at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportS
chemaError(XMLSchemaValidator.java:3182)
        at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleS
tartElement(XMLSchemaValidator.java:1806)
        at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startEl
ement(XMLSchemaValidator.java:705)
        at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scan
StartElement(XMLNSDocumentScannerImpl.java:400)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImp
l$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2756)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(X
MLDocumentScannerImpl.java:648)
        at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
(XMLNSDocumentScannerImpl.java:140)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImp
l.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(X
ML11Configuration.java:808)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(X
ML11Configuration.java:737)
        at com.sun.org.apache.xerces.internal.jaxp.validation.StreamValidatorHel
per.validate(StreamValidatorHelper.java:144)
        at com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.vali
date(ValidatorImpl.java:111)
        at javax.xml.validation.Validator.validate(Validator.java:127)
        at com.tangosol.run.xml.SaxParser.validateXsd(SaxParser.java:236)
        at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:206)
So I think that if can off JVM heap Memory used in the Near-Cache front-tier?
Or can help how to config the off JVM heap Memory used in the Near-Cache front-tier.
Thanks.

Only local-scheme and class-scheme can be used in the front-scheme of a near cache.

How to get cache statistics of back map in a near cache

Hi-
I have a near cache configured.
Local cache makes the front cache and Distributed cache makes the back cache.
I am able to get statistics of front cache using coherence API, like as below.
NamedCache coherenceCache = CacheUtils.getNamedCache( CacheUtils.getCacheRegionPrefix() + region.getRegionName() );
          if (coherenceCache instanceof NearCache)
               NearCache nearCache = (NearCache)coherenceCache;
               CachingMap cachingMap = (CachingMap)nearCache;
               CacheStatistics frontStatistics = ((LocalCache)nearCache.getFrontMap()).getCacheStatistics();
How do i get the statistics of back map?
If i do below, it gives statistics which combines data for both front and back (That is what i infer based on my understanding - it increases get count in both front and back even if get it done in front cache)
               CacheStatistics backStatistics = cachingMap.getCacheStatistics();
So is there any way to get statistics for back cache alone with Coherence API for a near cache?
Any help on this be much appreciated
thanks

Hi,
NamedCache coherenceCache = CacheUtils.getNamedCache( CacheUtils.getCacheRegionPrefix() + region.getRegionName() );
if (coherenceCache instanceof NearCache)
NearCache nearCache = (NearCache)coherenceCache;
CachingMap cachingMap = (CachingMap)nearCache;
Map backingMap = cachingMap.getBackMap();
OR
Map backingMap = nearCache.getBackMap();
getFrontMap() and getBackMap() are methods from CachingMap.
Thanks & Regards,
Murali.
============

About using OSB JMX Monitoring API

hi Experts,
My customer is using OSB11.1.1.7, they are trying to use JMX Monitoring API to get the statistic info, but have the following issues:
1. For the non-soap service, the serviceDomainMbean.getBusinessServiceStatistics method always return error when typeFlag was set with ResourceType.WEBSERVICE_OPERATION.value(), reason is there is no ws operation for this service, customer wants to know how to know if a service has no ws operation ,therefore they can avoid to get ws-operation statistic info for those kind of services.
2. Is there a way to get statistic info for the current aggregation interval? the api seems works with period from last reset.
3. Further more, How to get statistic info for special period, for example, customer want to query statistic info from 05/01 to 05/03, or from 05/03 12:00 to 05/03 13:00
Thanks for the help.
Best regards

Davinder Singh wrote:
Hi ,
I have an application deployed on weblogic server 8.1 . This has some MBeans exposed
for management purposes. This needs to be accessed from another web application
running on another weblogic instance on different machine. For this the managed
application has a Connector server and the management application is trying to
connect it through Connector client.
At the managed application side , i am getting NoSuchMethodError: javax.management.MBeanServer.getClassLoaderRepository()
I am not using weblogic implementation of JMX (MBean Server).
My guess about the error :the weblogic implements JMX version 1.0 and i am using
JMX remoting API (RI from Sun) which requires JMX 1.2
Is there a way i can make weblogic use JMX 1.2 ?I dont think there is a way to do this. But I might be wrong.
>
Thanx,
Davinder

Building a better near cache

I'm currently putting some code together to use for frequently updated data. The data set is large enough to warrant a distributed cache, and it will be read frequently by other cluster members than the key owner. To add to this, when the data changes it will trigger some business logic on the cluster members that had previously read the data.
In effect, it is a distributed cache in which clients can subscribe to particular keys to be notified when the underlying data changes.
The data is volatile and has very high update frequency so there's no point in backing it up on a second node, so I've configured a distributed-cache with 0 backups.
I've implemented a working prototype by wrapping a near cache and front-map listener. The wrapper maintains a set of current subscribers for each key, and each time a key is invalidated as per the near-schemes invalidation strategy the value is re-requested if the subscriber set is non empty. This works fine, but I'd like to get rid of the extra invalidate and get packages and instead get the updated value sent directly instead of the invalidation.
So here's a couple of questions:
1) Is it possible to get this behaviour from a near cache out of the box (docs are slightly vague, and I haven't been able to get it to work by trial and error)
2) If I were to stop using a near-cache and register a map listener for the keys directly on the distributed cache:
a) is the key match evaluated on the object form or the binary representation of the cached key - I'm concerned about the cpu overhead when deserialising the keys?
b) if there's more than one listener for the specified key, will the update package be sent using unicast or multicast?

Hi Henric,
I gave some thinking on this since yesterday.
It might be worth investigating to see if you could override the listener handling and registration methods which near cache uses so that you could use whatever notifications are sent anyway.
1. : I can't answer this at the moment.
2. a: I believe the key match is done on the binary key. I don't see any reason why not to use the binary key.
2. b: I think it depends on how many listeners. Look at the documentation of the multicast-threshold-percent setting within the multicast-listener configuration.
Best regards,
Robert

Hot key detection in a near cache?

I found this example to detect hot keys in a distributed cache server:
http://wiki.tangosol.com/pages/viewpage.action?pageId=16686
How would I accomplish the same thing but for a near cache?
thanks
sam

Hi,
NamedCache coherenceCache = CacheUtils.getNamedCache( CacheUtils.getCacheRegionPrefix() + region.getRegionName() );
if (coherenceCache instanceof NearCache)
NearCache nearCache = (NearCache)coherenceCache;
CachingMap cachingMap = (CachingMap)nearCache;
Map backingMap = cachingMap.getBackMap();
OR
Map backingMap = nearCache.getBackMap();
getFrontMap() and getBackMap() are methods from CachingMap.
Thanks & Regards,
Murali.
============

Storage disabled nodes and near-cache scheme

This probably is a newbie question. I have a named cache with a near cache scheme, with a local-scheme as the front tier. I can see how this will work in a cache-server node. But I have a application node which pushes a lot of data into the same named cache, but it is set to be storage disabled.
My understanding of a local cache scheme is that data is cached locally in the heap for faster access and the writes are delegated to the service for writing to backing map. If my application is storage disabled, is the local cache still used or is all data obtained from the cache-servers?

Hello,
You understanding is correct. To answer your question writes will always go through the cache servers. A put will also always go through the cache servers but the near cache may or may not be populated at that point.
hth,
-Dave

Stale Near Cache data when all Cache Server fails and are restarted

Hi,
We are currently making use of Coherence 3.6.1. We are seeing an issue. The following is the scenario:
- caching servers and proxy server are all restarted.
- one of the cache say "TestCache" is bulk loaded with some data (e.g. key/value of : key1/value1, key2/value, key3/value3) on the caching servers.
- near cache client connects onto the server cluster via the Extend Proxy Server.
- near cache client is primed with all data from the cache server "TestCache". Hence, near cache client now has all key/values locally (i.e. key1/value1, key2/value, key3/value3).
- all caching servers in the cluster is down, but the extend proxy server is ok.
- all cache server in the cluster comes back up.
- we reload all cache data into "TestCache" on the cache server, but this time it only has key/value of : key1/value1, key2/value.
- So the caching server's state for "TestCache" is that it should only have key1/value1, key2/value, but the near cache client still thinks it's got key1/value1, key2/value, key3/value3. So in effect, it still knows about key3/value3 which no longer exists.
Is there anyway for the near cache client to invalidate the key3/value3 automatically? This scenario happens because the extend proxy server is actually not down, but all caching servers are, but the near cache client for some reason doesn't know about this and does not invalidate the cache client near cache data.
Can anyone help?
Thanks
Regards
Wilson.

Hi,
I do have the invalidation strategy as "ALL". Remember this cache client is connected via the Extend proxy server where it's connectivity is still ok, just the caching server holding the storage data in the cluster are all down.
Please let me know why else we can try.
Thanks
Regards
Wilson.

Limiting JMX Monitor Executor Pool size

Hi all,
does anybody know how to limit (or in general, set) the size of the Scheduler/Executor Pool in JMX for Monitors?
By default it seems that 10 threads are created, named [JMX Monitor Executor Pool [Thread-n]]. They get created when I create the first Monitoring MBean, in my case this was a simple GaugeMonitor.
I don't have a problem with the 10 threads, but its just that our app already has enough threads as it is, plus the granularity period we will use is fairly big (minutes) and we only have a few Monitor beans, so we won't have high load on them.
Any help appreciated.
Cheers, Mark

Mark,
You can set the system property jmx.x.monitor.maximum.pool.size to control this, either on the command line with e.g. -Djmx.x.monitor.maximum.pool.size=3 or by calling System.setProperty("jmx.x.monitor.maximum.pool.size", "3"). The value of this property is consulted the first time the class javax.management.monitor.Monitor is loaded (typically when you create your first monitor), and not thereafter, so you must be sure to set it beforehand.
This property is non-standard and will not necessarily work with other implementations of the JMX API, but it does work with the implementation that is in the JDK platform, starting with JDK 6. (Before JDK 6, every monitor had its own thread, so if you are seeing a limit of 10 threads then you are using JDK 6.)
From my reading of the code, it does look as if more threads will be created than strictly necessary. For example, if you only have one monitor then you don't need more than one thread, but if the monitor's granularity period is less than 60 seconds you will end up with 60/period threads, up to the maximum (default 10). For example 4 threads if the period is 15 seconds. I think we should probably fix that. (The core pool size should probably be 1 rather than the same as the max pool size.)
Regards,
�amonn McManus -- JMX Spec Lead -- [http://weblogs.java.net/blog/emcmanus]

The JMX Monitoring APIs for OSB

hi
I know Using the JMX Monitoring APIs can monitor Oracle Service Bus at run time to know how many messages in a particular service have processed successfully and how many have failed. but those are Statistical Information . i want to monitor the details when a particular service is invoked,such as the caller's IP address, the call is successful or not, the error message and error code.
帖子经 David编辑过

There are no public API that are present except for monitoring and Deployment.
http://download.oracle.com/docs/cd/E14571_01/doc.1111/e15867/app_apis.htm#CHDHAJGD
The runtime information for OSB artifacts and their instances are not exposed though API.This use-case can be accomplished by using reporting action. http://download.oracle.com/docs/cd/E14571_01/doc.1111/e15867/reporting_console.htm#CACJFDGF
Getting IP address of cleints invoking proxy on OSB is little tricky, but some transports do support. eg HTTP. Can you describe in brief actual business case so that we can come-up with some solution. Is this monitoring, part of Business logic or Administrator requirement (Technical) etc.
Thanks
Manoj

Example of a Coherence near cache config.

Looking at the wiki, it states that the near cache is
Listener-based Near caches are coherent; expiry-based near caches are partially coherent for non-transactional reads and coherent for transactional access.
Is there a configuration file example for a listener-based near cache?

Hi George,
Near cache example: Local cache of a partitioned cache (Near cache).
invalidation-strategy element of a near-scheme specifies the strategy used keep the front-tier in-sync with the back-tier:
* none - instructs the cache not to listen for invalidation events at all. This is the best choice for raw performance and scalability when business requirements permit the use of data which might not be absolutely current. Freshness of data can be guaranteed by use of a sufficiently brief eviction policy. The worst case performance is identical to a standard Distributed cache.
* present - instructs the near cache to listen to the back map events related only to the items currently present in the front map.
This strategy works best when cluster nodes have sticky data access patterns (for example, HTTP session management with a sticky load balancer).
* all - instructs the near cache to listen to all back map events.
This strategy is optimal for read-heavy access patterns where there is significant overlap between the front caches on each cluster member.
* auto - instructs the near cache to switch between present and all strategies automatically based on the cache statistics.
Regards,
Dimitri

Near Cache JMX Monitoring

Similar Messages

Maybe you are looking for