Created attachment 965582 [details] C++ sample code to reproduce this issue Description of problem: C++ HotRod Client has wrong cache size after the key/value is expired when using lifespan Version-Release number of selected component (if applicable): RHEL 6.4 64 bit JBoss Data Grid 6.3.0 GA C++ HotRod Client Steps to Reproduce: 1. Start JDG 6.3.0 server; 2. Using C++ HotRod Client to connect to server; 3. Using C++ HotRod Client to create a key/value to set the lifespan is 3 seconds, and the size is 1 and you can get the key/value; 4. After 3 seconds, you will not get the key/value but the size is still 1;
this issue doesn't exist in JAVA HotRod client.
Created attachment 965583 [details] Java HotRod Client doesn't have this issue
The native client is using HotRod Protocol 1.2 and size() is implemented using server statistics, more specifically the "currentNumberOfEntries" stat which doesn't seem to be updated as soon as the entry expires. Version 2.0 of the protocol introduced a proper Size operation. We would need to implement 2.0 in the native client to fix this (the java client is already using this operation and this is why for that client the test works fine).
Additionally the "currentNumberOfEntries" statistic is broken since it returns the size of the data container of the node responding to the request which doesn't take into account: eviction/expiration/persistence/distribution/etc.
One possible fix for this issue would be to use the same HotRod protocol version (1.2) in the Java and C++ clients in the product. Then they would be consistent with each other until the new protocol is implemented in all of the clients.
I just realised that for the JDG Java client the behavior is actually identical as the size operation is not used and the same stat ("currentNumberOfEntries") is used instead. Tested using JDG-6.4.0-ER7-redhat-1 using the attached code and both clients give the correct answer if a get() is performed on the expired keys prior to size() and the wrong answer if a prior get() is not performed.
Let's exclude this from CR1 until we have had another chat with Tristan about this.
Verified with JDG 6.4.0 ER8
In the case of a cache with eviction/passivation to a cachestore, the entries present on the cachestore will be included in the count returned by the size() operation