[infinispan-issues] [JBoss JIRA] (ISPN-10176) ClusterCacheStatsImpl not picking up NonTxInvalidationInterceptor for non-tx invalidation cache

[Koen Serneels (Jira)]

     [ https://issues.jboss.org/browse/ISPN-10176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Serneels updated ISPN-10176:
---------------------------------
    Description: 
We are using a clustered non-tx <invalidation-cache> for which we enable JMX stats. The invalidation counter reported by ClusterCacheStatsImpl remains always zero. 

Further investigation showed that a NonTxInvalidationInterceptor is created for the cache, but not picked up by ClusterCacheStatsImpl since it's trying to retrieve the interceptor like this:

{code:java}
   //invalidations
         InvalidationInterceptor invalidationInterceptor = getFirstInterceptorWhichExtends(remoteCache,
               InvalidationInterceptor.class);
         if (invalidationInterceptor != null) {
            map.put(INVALIDATIONS, invalidationInterceptor.getInvalidations());
         } else {
            map.put(INVALIDATIONS, 0);
         }
{code}

But NonTxInvalidationInterceptor does not extend InvalidationInterceptor. Further more the javadoc states:

{code:java}
/**
** This interceptor should completely replace default InvalidationInterceptor.*
...
..
.
{code}

  was:
We are using a clustered non-tx <invalidation-cache> for which we enable JMX stats. The invalidation counter reported by ClusterCacheStatsImpl remains always zero. 

Further investigation showed that a NonTxInvalidationInterceptor is created for the cache, but not picked up by ClusterCacheStatsImpl since it's trying to retrieve the interceptor like this:

{code:java}
   //invalidations
         InvalidationInterceptor invalidationInterceptor = getFirstInterceptorWhichExtends(remoteCache,
               InvalidationInterceptor.class);
         if (invalidationInterceptor != null) {
            map.put(INVALIDATIONS, invalidationInterceptor.getInvalidations());
         } else {
            map.put(INVALIDATIONS, 0);
         }
{code}

But NonTxInvalidationInterceptor does not extend InvalidationInterceptor. Further more the javadoc states:

{code:java}
/**
** * This interceptor should completely replace default InvalidationInterceptor.**
 * We need to send custom invalidation commands with transaction identifier (as the invalidation)
 * since we have to do a two-phase invalidation (releasing the locks as JTA synchronization),
 * although the cache itself is non-transactional.
 *
{code}



> ClusterCacheStatsImpl not picking up NonTxInvalidationInterceptor for non-tx invalidation cache
> -----------------------------------------------------------------------------------------------
>
>                 Key: ISPN-10176
>                 URL: https://issues.jboss.org/browse/ISPN-10176
>             Project: Infinispan
>          Issue Type: Bug
>    Affects Versions: 9.4.13.Final
>            Reporter: Koen Serneels
>            Priority: Major
>
> We are using a clustered non-tx <invalidation-cache> for which we enable JMX stats. The invalidation counter reported by ClusterCacheStatsImpl remains always zero. 
> Further investigation showed that a NonTxInvalidationInterceptor is created for the cache, but not picked up by ClusterCacheStatsImpl since it's trying to retrieve the interceptor like this:
> {code:java}
>    //invalidations
>          InvalidationInterceptor invalidationInterceptor = getFirstInterceptorWhichExtends(remoteCache,
>                InvalidationInterceptor.class);
>          if (invalidationInterceptor != null) {
>             map.put(INVALIDATIONS, invalidationInterceptor.getInvalidations());
>          } else {
>             map.put(INVALIDATIONS, 0);
>          }
> {code}
> But NonTxInvalidationInterceptor does not extend InvalidationInterceptor. Further more the javadoc states:
> {code:java}
> /**
> ** This interceptor should completely replace default InvalidationInterceptor.*
> ...
> ..
> .
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)