JBossCache Cache Mgmt interceptor hit/miss not collected wit

[mabc101]

I am using JBossCache (1.4) and I have a question regarding cache management stats collection -

1. when a call is made to treeCache.put(String, Object), the stats for hits/misses are not collected, and
2. when the call is made to treeCache.put(String, Object, Object), the stats are collected. The second argument in the second call is the key.

I've traced the call to the CacheMgmtInterceptor.invoke() (line 134) method. I just wanted to find out why is the hit/miss stats collection case skipped in the first case (without the key) vs the second case (with second argument as key) mentioned above and ? Are there any guidelines as to when to use the first method vs the second ?

[manik]

If this is the case then it is probably a bug. Do you have a unit test for this? If so, I'd recommend creating a JIRA issue for this, along with your unit test, and we'll investigate.

[mabc101]

Thanks Manik for your prompt response.

I am including the section of the code from CacheMgmtInterceptor below.
As you can see the case statement for "get" which keeps hit/miss stats count, is for "getKeyValueMethodLocal" case only. If I call the method without the key (as indicated in my previous post), the default case is invoked, so the hit/miss count is not captured.

I believe this is by design and I just want to understand the semantic difference between the two cases, ie, using "get" without key has a different purpose (perhaps internally - like node visits for eviction etc - which logically should not increment the hit/miss count - but I am treading on this ice here) vs "get" with key which actually returns data and therefore should update the stats.

Here is the code segment:

==============================================

switch (m.getMethodId())
{
case MethodDeclarations.getKeyValueMethodLocal_id:
//fqn = (Fqn) args[0];
//key = args[1];
t1 = System.currentTimeMillis();
retval=super.invoke(m);
t2 = System.currentTimeMillis();
if (retval == null)
{
m_miss_times = m_miss_times + (t2 - t1);
m_misses++;
}
else
{
m_hit_times = m_hit_times + (t2 - t1);
m_hits++;
}
break;
case MethodDeclarations.putKeyValMethodLocal_id:
case MethodDeclarations.putFailFastKeyValueMethodLocal_id:
//fqn = (Fqn) args[1];
//key = args[2];
//value = args[3];
t1 = System.currentTimeMillis();
retval=super.invoke(m);
t2 = System.currentTimeMillis();
m_store_times = m_store_times + (t2 - t1);
m_stores++;
break;
case MethodDeclarations.putDataMethodLocal_id:
case MethodDeclarations.putDataEraseMethodLocal_id:
//fqn = (Fqn) args[1];
attributes = (Map)args[2];
t1 = System.currentTimeMillis();
retval=super.invoke(m);
t2 = System.currentTimeMillis();

if (attributes != null && attributes.size() > 0)
{
m_store_times = m_store_times + (t2 - t1);
m_stores = m_stores + attributes.size();
}
break;
case MethodDeclarations.evictNodeMethodLocal_id:
case MethodDeclarations.evictVersionedNodeMethodLocal_id:
//fqn = (Fqn) args[0];
retval=super.invoke(m);
m_evictions++;
break;
default :
retval=super.invoke(m);
break;
}

return retval;
}

[manik]

This looks like a bug to me. I can't see how this is by design.

[mabc101]

Sounds good to me.

Thanks.

[manik]

Once you create the JIRA post a link to it here.

Thanks
Manik

[mabc101]

Unfortunately, I do not have unit test. I discovered the issue by stepping into the code. If you have some testing framework I can perhaps create a test case and then open JIRA issue.

[manik]

Check out the JBoss Cache source code from SVN. You can then add a test to the test suite there, try it out and email me the diff. I'd use the 1.4 branch.

http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheDevelopment

[jerrygauth]

Sorry - I've been away on vacation and am just now catching up on this thread.

The decision to not include puts and gets of "nodes" in the statistics was made when we added statistics support in late 2005. I don't recall whether there was a forum discussion but the issue is addressed briefly in JBossCache source control under \docs\design\ManagementAttributes.txt. This document notes that we arbitrarily decided to not include "nodes" in those statistics counters.

This can certainly be revisited and modified as appropriate. One design issue is how the counters should be incremented when a node is put or read. If you put a node containing 5 attributes, is that 1 write operation or 5? Same issue for gets of nodes.

Jerry