cache loader class instantiated twice?| JBoss.org Content Archive (Read Only)

1. Re: cache loader class instantiated twice?

mircea.markus Jan 4, 2010 6:42 AM (in response to amin59)

A cache loader is instantiated for each used cache. If you have multiple active caches associated to a cache managers, than this might be the reason. Otherwise, instantiating a cache loader twice doesn't really make sense - if this is the case, mind crearting a jira for this?

2. Re: cache loader class instantiated twice?

amin59 Jan 16, 2010 4:04 AM (in response to mircea.markus)

https://jira.jboss.org/jira/browse/ISPN-333

3. Re: cache loader class instantiated twice?

amin59 Jan 20, 2010 1:47 AM (in response to amin59)

Maybe I do something wrong, but bellow is my scenario. The point is that once cache store is created in

manager = new DefaultCacheManager(configInputStream)

step and once again when I get it via

cache = manager.getCache("accounts");

Here is my code to get a reference to cache:

final CacheManager manager;

try {
    manager = new DefaultCacheManager(configInputStream);
} catch (IOException e) {
    throw new ExceptionInInitializerError(e);
}

cache = manager.getCache("accounts");

I could provide more details but I think the most informative one is the relevent stack-traces.

Here is the stack-trace of first creation

     at com.magfa.gateway.dao.infinispan.jdbcstore.AccountJdbcCacheStore.(AccountJdbcCacheStore.java:40)
     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
     at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
     at java.lang.Class.newInstance0(Class.java:355)
     at java.lang.Class.newInstance(Class.java:308)
     at org.infinispan.util.Util.getInstance(Util.java:79)
     at org.infinispan.util.Util.getInstance(Util.java:87)
     at org.infinispan.loaders.CacheLoaderConfigAdapter.unmarshal(CacheLoaderConfig.java:70)
     at org.infinispan.loaders.CacheLoaderConfigAdapter.unmarshal(CacheLoaderConfig.java:54)
     at com.sun.xml.internal.bind.v2.runtime.reflect.AdaptedLister.addToPack(AdaptedLister.java:67)
     at com.sun.xml.internal.bind.v2.runtime.unmarshaller.Scope.add(Scope.java:106)
     at com.sun.xml.internal.bind.v2.runtime.property.ArrayERProperty$ReceiverImpl.receive(ArrayERProperty.java:195)
     at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallingContext.endElement(UnmarshallingContext.java:507)
     at com.sun.xml.internal.bind.v2.runtime.unmarshaller.ValidatingUnmarshaller.endElement(ValidatingUnmarshaller.java:84)
     at com.sun.xml.internal.bind.v2.runtime.unmarshaller.SAXConnector.endElement(SAXConnector.java:145)
     at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
     at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1774)
     at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2930)
     at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
     at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
     at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
     at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
     at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
     at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
     at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
     at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
     at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:200)
     at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:173)
     at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:137)
     at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:105)
     at org.infinispan.config.InfinispanConfiguration.newInfinispanConfiguration(InfinispanConfiguration.java:217)
     at org.infinispan.manager.DefaultCacheManager.(DefaultCacheManager.java:261)
     at org.infinispan.manager.DefaultCacheManager.(DefaultCacheManager.java:247)
     at com.magfa.gateway.dao.infinispan.InfinispanBillingDao.(InfinispanBillingDao.java:90)

And here is the second once (i.e. when I getCache()):

     at com.magfa.gateway.dao.infinispan.jdbcstore.AccountJdbcCacheStore.(AccountJdbcCacheStore.java:40)
     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
     at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
     at java.lang.Class.newInstance0(Class.java:355)
     at java.lang.Class.newInstance(Class.java:308)
     at org.infinispan.util.Util.getInstance(Util.java:79)
     at org.infinispan.util.Util.getInstance(Util.java:87)
     at org.infinispan.loaders.CacheLoaderManagerImpl.createCacheLoader(CacheLoaderManagerImpl.java:186)
     at org.infinispan.loaders.CacheLoaderManagerImpl.createCacheLoader(CacheLoaderManagerImpl.java:171)
     at org.infinispan.loaders.CacheLoaderManagerImpl.start(CacheLoaderManagerImpl.java:95)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170)
     at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:846)
     at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:666)
     at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:572)
     at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:147)
     at org.infinispan.CacheDelegate.start(CacheDelegate.java:304)
     at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:390)
     at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:354)
     at com.magfa.gateway.dao.infinispan.InfinispanBillingDao.(InfinispanBillingDao.java:95)

Here is my XML cache-config (loader for named cache accounts)

<loader class="com.magfa.gateway.dao.infinispan.jdbcstore.AccountJdbcCacheStore"

ignoreModifications="false"
purgeOnStartup="false">

</loader>

</loaders>

And my cache-store which simply extends AbstractCacheStore, and its config is also very simple:

public class AccountJdbcCacheStoreConfig extends AbstractCacheStoreConfig {
}

public class AccountJdbcCacheStore extends AbstractCacheStore {
}

4. Re: cache loader class instantiated twice?

manik Jan 20, 2010 7:51 AM (in response to amin59)

Aha, I see the problem. Note that this only happens if you construct a CacheManager using an XML file or InputStream, which is why it never turned up in my tests (I used a GlobalConfiguration and Configuration bean, configured programmatically).

The issue is that each CacheStore impl has a corresponding CacheStoreConfig impl, which has knowledge of settings specific to the CacheStore impl in question. When configuring stuff programmatically, you simply create a new instance of the CacheStoreConfig impl and pass it to the Configuration (e.g., a new FileCacheStoreConfig).

But when you do this via XML, all CacheStore settings are maintained using <property ... /> tags. So we need to know what type of CacheStoreConfig to instantiate and pass these properties to. And the mechanism currently in place to do this is to instantiate the CacheStore implementation and call CacheStore.getConfigurationClass(). The CacheStore instance is then thrown away since the cache hasn't started yet (this is still at a much earlier phase, of parsing XML).

In summary, I will reopen ISPN-333 and investigate how this can be improved, but this is low prio since the first instantiation happens on startup and has no effect or cost to runtime performance.

Cheers

Manik

5. Re: cache loader class instantiated twice?

manik Mar 9, 2010 7:43 AM (in response to manik)

A quick update, I just checked in @CacheLoaderMetadata into trunk (scheduled for 4.1.0) and this will help prevent this problem. See the JIRA for details.