CacheLoader configuration issue when configuring by code.

[dcarniel]

As described in a previous thread, I face issues when trying to configure my own cache loader using the programmatic approach (using a configuration file wouldn't be a practical option in my case).

When passing an instance of MyCacheLoader to the configuration and adding some properties to configure it, I get an error message stating that the properties cannot be found on AbstractCacheStoreConfig, which is correct since this is not my class, the point would be to understand why this class is instantiated whereas my cache loader provides a reference of its own configuration class.

The attached example shows the behaviour I get. It is a simple maven project, the cache loader and its configuration class are in the "src/main" part and a simple unit test was written to show the issue.

I'd be glad if someone can shed light on this.

[dcarniel]

After reviewing my example I noticed there was an annotation in the ClusterCacheLoader class that I do not have. Adding it prevented the error for the property not available on AbstractCacheStoreConfig, but the properties do not seem to be called either as the prefix used is the default one whereas configuration object should be set with a different value.

Attached is an updated version (I also added the getCacheLoaderClassName() method in my configuration class).

[dcarniel]

Tracing what happens in Infinispan classes, I noticed something surprising in the "LegacyConfigurationAdaptor" class (starting at line 197):

         if (clc instanceof CacheStoreConfig) {
            CacheStoreConfig csc = (CacheStoreConfig) clc;
            csc.fetchPersistentState(loader.fetchPersistentState());
            csc.ignoreModifications(loader.ignoreModifications());
            csc.purgeOnStartup(loader.purgeOnStartup());  
            csc.setPurgeSynchronously(loader.purgeSynchronously());
            csc.getAsyncStoreConfig().setEnabled(loader.async().enabled());
            csc.getAsyncStoreConfig().flushLockTimeout(loader.async().flushLockTimeout());
            csc.getAsyncStoreConfig().modificationQueueSize(loader.async().modificationQueueSize());
            csc.getAsyncStoreConfig().shutdownTimeout(loader.async().shutdownTimeout());
            csc.getAsyncStoreConfig().threadPoolSize(loader.async().threadPoolSize());
            
            csc.getSingletonStoreConfig().enabled(loader.singletonStore().enabled());
            csc.getSingletonStoreConfig().pushStateTimeout(loader.singletonStore().pushStateTimeout());
            csc.getSingletonStoreConfig().pushStateWhenCoordinator(loader.singletonStore().pushStateWhenCoordinator());
         }
         if (clc instanceof AbstractCacheStoreConfig) {
            AbstractCacheStoreConfig acsc = (AbstractCacheStoreConfig) clc;
            Properties p = loader.properties();
            acsc.setProperties(p);
            if (p != null) XmlConfigHelper.setValues(clc, p, false, true);
            if (loader instanceof LoaderConfiguration)
               acsc.purgerThreads(((LoaderConfiguration) loader).purgerThreads());
         }

It seems to me that the second if statement should check for an instance of AbstractCacheLoaderConfig so both cache loaders and cache stores see their properties assigned.

Changing my configuration class from "extends AbstractCacheLoaderConfig" to "extends AbstractCacheStoreConfig" triggers a call to the setter (though the code doesn't work as I've a cache loader and not a cache store).

[mgencur]

I tried your code and after extending AbstractCacheStore by MyCacheLoader and adding unimplemented methods (empty methods) the test passes.

The LegacyConfigurationAdaptor implies that you can only set properties in this way if you extend AbstractCacheStore and your configuration class extends AbstractCacheStoreConfig, so basically only if you have a cache store, not cache loader.

[sannegrinovero]

Hi dcarniel,

you're right, that is a problem. In fact that's one of the reasons for some tests to fail currently on master: the migration from the older configuration parser to the new one is making progress, and this is revealing some problems in the LegacyConfigurationAdapter, like the one you spotted.

For now please follow Martin's suggestion as a temporary workaround, we should remove the adapter soon so it's not worth attempting to fix it.

[dcarniel]

Hi,

I sure can use the workaround described (though writing a CacheStore that is in fact a CacheLoader isn't that nice ).

Now if that could be of help for a next release, I wrote a tentative fix by changing the second if statement (starting from line 213) as follow and it worked for me.

      if ((clc instanceof AbstractCacheLoaderConfig)) {
        AbstractCacheLoaderConfig aclc = (AbstractCacheLoaderConfig)clc;
        Properties p = loader.properties();
        aclc.setProperties(p);
        if (p != null) XmlConfigHelper.setValues(clc, p, false, true);
        if ((aclc instanceof AbstractCacheStoreConfig)) {
          ((AbstractCacheStoreConfig)aclc).purgerThreads(Integer.valueOf(((LoaderConfiguration)loader).purgerThreads()));
        }
      }

Feel free to integrate this if that can be useful.

Thanks for confirming my findings.

Regards,

Denis

[galder.zamarreno]

As indicated in https://issues.jboss.org/browse/ISPN-2059, those changes you suggest might not fully work with other cache stores. Just so that you're aware.