RemoteCache.stat().getStatsMap()

[raghav_11]

Hi,

    I would like to know what the method attributes define in distributed cache. I am running two hotrod servers and owners=2.

HOTROD SERVER1

numberOfEntries: 1567

  misses: 15049

  removeHits: 0

  timeSinceReset: 24280

  averageRemoveTime: 0

  statisticsEnabled: true

  removeMisses: 0

  hitRatio: 0.04921657821582007

  evictions: 0

  hits: 779

  readWriteRatio: 10.23803363518758

  averageReadTime: 0

  elapsedTime: 24280

  stores: 1547

HOTROD SERVER2

numberOfEntries: 1567

  misses: xxxx

  removeHits: 0

  timeSinceReset: xxxxx

  averageRemoveTime: 0

  statisticsEnabled: true

  removeMisses: 0

  hitRatio: 0.04921657821582007

  evictions: 0

  hits: 779

  readWriteRatio: 10.23803363518758

  averageReadTime: 0

  elapsedTime: 24280

  stores: 1546

what does number of Entries,Total no of entries and stores actually represent??

In my case, my desired value matches only with stores( which is number of put operations). But i expect number of Entries to be 1546( i have 1546 entries in DB which am adding in cache) . How it actually works in distributed servers? Both servers differing in values too.can someone explain??

Thanks,

Raghav.

[wdfink]

The number of enties is counted local on this server and may not reflect the total number. Also it might change everytime you look to.

If you have a replicated cache it will be the same on all nodes.

Does that makes sense to you?

[raghav_11]

Hi,

             Then if i have 100 entries and maintaining a JBoss distributed cache with 2 HotRod servers with owner = 1,

then  Server1 will be having 50 entries(say)

          Server2 will be having 50 entries(say)

In server 1 stats,

Number of entries = 50

Total Number of Entries = 100

stores = may vary according to number of put operation.

In case of replicated cache, current Number of Entries will be always equal to total Number of entries.

Am i right in my understanding.Please correct me if i am wrong?????

[wdfink]

That's sound correct to me, the balance might vary because of the calculated hash

[raghav_11]

I am using jbossData grid -6.2.1.

<distributed-cache mode="SYNC" name="circuitgraphcache" owners="2" remote-timeout="30000" segments="30" start="EAGER">

        <locking acquire-timeout="30000" concurrency-level="1000" isolation="READ_COMMITTED" striping="false"/>

        <eviction max-entries="5" strategy="LRU"/>

    </distributed-cache>

For the above configuration, my cache.stat().getStatsMap() method shows output  in client

,

Cache Name

:circuitgraphcache

circuitgraphcache size =  ::  5

hits  ::  39

currentNumberOfEntries  ::  4

totalBytesRead  ::  90064911

timeSinceStart  ::  2366

totalNumberOfEntries  ::  11

totalBytesWritten  ::  30477556

removeMisses  ::  0

removeHits  ::  0

retrievals  ::  50

stores  ::  11

misses  ::  11

I am using two hotrod servers with above configuration same in both servers. Even though cache size not increasing above 5(max-entries =5 as i specified). i couldn't still understand the value of currentNumber of entries,Total no. of entries.

What i expect in my case is ,

1)cache size(am using cache.keySet(0.size()) should be always equal to current number of entries.

2) Since distributed cache with owners=2 , 5 entries will be available in both server caches( making it behave like a replicated cache).

   So total number of entries should be equal twice current number of entries.

Am i right with my explanation as per previous logic which i told.

Can you explain me why am i getting different output than i expect?

Which attribute should i check to know the exact number of entries in the remote distributed-cache as a whole?

Thanks & Regards,

Raghav.

[vbchin2]

Please go thru this interface definition to understand what each of them stats mean : ServerStatistics (Infinispan Distribution 7.0.3.Final API) . Disable or remove the Evinction entry for your tests. The max-entries entries here refers to the maximum entries that needs to be held by the cache container but the each segment can carry far less and based on the current design the eviction happens per segment. So you might see a situation that you are never hitting the max-entries limit.

More details below at : 2.4.1 and 2.4.3

Frequently Asked Questions