Wildfly.9.0.0CR1 Issues error for infinispan config

[nick.sree]

Getting error while starting Wildfly.9.0.0CR1 with infinispan cache config

ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration

  at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)

  at org.jboss.as.server.ServerService.boot(ServerService.java:347)

  at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:271)

  at java.lang.Thread.run(Thread.java:745)

Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[279,190]

Message: WFLYCTL0197: Unexpected attribute 'start' encountered

  at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:117)

  at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.parseContainer(InfinispanSubsystemXMLReader.java:123)

  at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.readElement(InfinispanSubsystemXMLReader.java:71)

  at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.readElement(InfinispanSubsystemXMLReader.java:49)

  at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)

  at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)

  at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1199)

  at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:457)

  at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:144)

  at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:106)

  at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)

  at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)

  at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)

  ... 3 more

Following is my configuration, bold lines in this config is our own cache config, where we have mentioned start="EAGER" . If we remove start="EAGER"  then wildfly starting but we are not getting cache reference using the JNDI name.

<subsystem xmlns="urn:jboss:domain:infinispan:3.0">

            <cache-container name="server" default-cache="default" module="org.wildfly.clustering.server">

                <local-cache name="default">

                    <transaction mode="BATCH"/>

                </local-cache>

            </cache-container>

            <cache-container name="web" default-cache="passivation" module="org.wildfly.clustering.web.infinispan">

                <local-cache name="passivation">

                    <transaction mode="BATCH"/>

                    <file-store passivation="true" purge="false"/>

                </local-cache>

                <local-cache name="persistent">

                    <transaction mode="BATCH"/>

                    <file-store passivation="false" purge="false"/>

                </local-cache>

            </cache-container>

            <cache-container name="ejb" default-cache="passivation" module="org.wildfly.clustering.ejb.infinispan" aliases="sfsb">

                <local-cache name="passivation">

                    <transaction mode="BATCH"/>

                    <file-store passivation="true" purge="false"/>

                </local-cache>

                <local-cache name="persistent">

                    <transaction mode="BATCH"/>

                    <file-store passivation="false" purge="false"/>

                </local-cache>

            </cache-container>

            <cache-container name="master" default-cache="master-data" jndi-name="java:jboss/infinispan/container/master-data" module="org.jboss.as.clustering.web.infinispan" start="EAGER">

                <local-cache name="master-data">

                    <transaction mode="NON_XA"/>

                    <eviction strategy="LRU" max-entries="10000"/>

                    <expiration max-idle="100000"/>

                </local-cache>

            </cache-container>

[jewellgm]

Is it possible for you to use the older schema for the infinispan subsystem?  If you use the 2.0 spec rather than the 3.0, it still contains the "start" attribute.  I don't know whether wildfly 9 will honor that parameter, but it may be worth a try.

[nick.sree]

I tried it but wildfly 9 not supporting it

[rhusar]

Please see [WFLY-4562] Deprecate Infinispan container/cache start mode - JBoss Issue Tracker.

[pferraro]

In summary - there is no longer any reason for an cache or cache-container to require start="EAGER".  In fact, this setting was probably the single most common headache for new users, hence its removal.

An application can ensure that a given cache is started by using an appropriate MSC or JNDI dependency.  Let me know if you need help with that.

[nick.sree]

Ok, then can you please help me on how to setup?

[jaikiran]

If we remove start="EAGER"  then wildfly starting but we are not getting cache reference using the JNDI name.

Please post the relevant code where you are looking up or injecting it. Also post any exception stacktraces you see with the lookup/injection.

[nick.sree]

Its a normal class (NO EJB) where trying to look up  EmbeddedCacheManager via "java:jboss/infinispan/container/master-data" jndi.

Context context = new InitialContext();

EmbeddedCacheManager cacheManager = (EmbeddedCacheManager) context.lookup("java:jboss/infinispan/container/master-data");

It throws

javax.naming.NameNotFoundException: infinispan/container/master-data

[jaikiran]

It's also important to know "when" that lookup happens. So please post the entire exception stacktrace as well as tell us a bit more about when that code is getting invoked.

[jaikiran]

One way to make sure that the server sets up the necessary dependencies before letting your lookup code run, is to add the right dependencies within your web.xml. For example, you could add this to your web.xml:

<resource-env-ref>
    <resource-env-ref-name>cache/master-data</resource-env-ref-name>
    <resource-env-ref-type>org.infinispan.manager.EmbeddedCacheManager</resource-env-ref-type>
    <lookup-name>java:jboss/infinispan/container/master-data</lookup-name>
</resource-env-ref>

to make sure that the JNDI name will be available before your lookup code is run.

[pferraro]

Expanding on what Jaikiran already said...

Adding a resource reference in this way not only ensures that the cache manager is available via JNDI lookup to your application, but also ensures that the cache manager and its dependencies are started when you application is deployed and stopped when no longer referenced (e.g. undeploy).  This also allows your code to utilize a standard JNDI namespace rather than the vendor specific "java:jboss" namespace.

[nick.sree]

Thanks Jaikiran and Paul, let me try with web.xml config and get back to you

[salamont]

Hi Paul,

We have probably the same problem with Wildfly 9.0.1.Final, however I wasn't able to solve it even with your recommendation. Our application is struggling with the injection of infinispan cache. We have tried everything possible, but the problem still is not solved.

We are calling a distributed cache that is clustered over two nodes (for testing purposes so far). We have also tried local caches, etc.: everything works. Even the distributed cache works time to time (completely randomly), especially when the test-bench is the only application on the server and therefore it is loaded fast. But in the vast majority of cases, we get the following error:

org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke public void cz.example.cacheBean.init() on cz.example.cacheBean@64bfe9cb

  at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:100)

  at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.postConstruct(DefaultLifecycleCallbackInvoker.java:81)

...

  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

  at java.lang.Thread.run(Thread.java:745)

Caused by: java.lang.reflect.InvocationTargetException

  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

  at java.lang.reflect.Method.invoke(Method.java:497)

  at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:98)

  ... 72 more

Caused by: javax.ejb.EJBException: java.lang.NullPointerException

  at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)

  at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)

  at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)

The code looks like:

@Stateless

public class InfinispanProgramBean implements InfinispanProgramBeanLocal {

    @Resource(lookup="java:jboss/infinispan/container/infinicheck")

    private CacheContainer container;

    private Cache<String, String> cache;

    //private EmbeddedCacheManager manager;

    private static final Logger log = LoggerFactory.getLogger("cz.mycomp.tests");

    public Cache<String, String> getMyCache() {

        if (cache == null) {

            cache = container.getCache();

            if (cache == null) {

                log.error("Cache is still null.");

            }

        }

        return cache;

    }

    @Override

    public void addToCache(String key, String value) {

        getMyCache().put(key, value);

    }

I have added the following into web.xml:

<resource-env-ref>

    <resource-env-ref-name>cache/default</resource-env-ref-name>

    <resource-env-ref-type>org.infinispan.manager.EmbeddedCacheManager</resource-env-ref-type>

    <lookup-name>java:jboss/infinispan/container/infinicheck</lookup-name>

</resource-env-ref>

And finally, in domain.xml under <subsystem xmlns="urn:jboss:domain:infinispan:3.0"> there is:

<cache-container name="infinicheck" default-cache="default" module="deployment.infinicheck-ear-0.1-SNAPSHOT.ear">

    <transport lock-timeout="60000"/>

    <distributed-cache name="default" mode="ASYNC" owners="2" l1-lifespan="0">

          <transaction mode="BATCH"/>

          <file-store/>

    </distributed-cache>

</cache-container>

I have already spent many many hours on this, but without any luck. I am currently using an ugly workaround. I put this distributed-cache definition into the standard web container. Hence it is always loaded and works like a charm. However I am not happy about such a solution for obvious reasons. Please, do you have any idea, where could be the problem? Many thanks.

Tomas

[pferraro]

A few things:

1. If you plan to inject a server-managed Infinispan resource into your application, make sure your application doesn't include the infinispan jars, but instead reference the server module via module dependency.  e.g. in your MANIFEST.MF, add the line: "Dependencies: org.infinispan"
2. Why not inject the cache directly? e.g. @Resource(lookup = "java:jboss/infinispan/cache/infinicheck/default") Cache<String, String> cache;  In fact, unless you plan to use Infinispan-specific Cache methods, you can type your cache a ConcurrentMap<String, String> or even a Map<String, String>.  That way, you don't need to import the infinispan API in your application at all.
3. There should be no need to use a <resource-env-ref/> if you don't plan to use the JNDI resource via its java:comp/env namespace.  I usually recommend that users do this, so as to not reference a vendor specific namespace in their applications.
4. In your infinispan subsystem configuration, you have defined module="deployment.infinicheck-ear-0.1.SNAPSHOT.ear", but I'm not sure that the module will exist when the cache container starts.  Is there a specific reason why you need this?

[salamont]

Hi Paul, thank you for your reply. However, I am afraid we still have the problem

(Just to remember, currently the version used is Wildfly 9.0.1.Final).

ad 1) Yes, of course, we are doing it. In maven, infinispan dependencies as provided and also in MANIFEST.MF, The problem is not there, time to time the cache works.

ad 2) @Resource(lookup = "java:jboss/infinispan/cache/infinicheck/default")  - Yes, we did. And it is the problem. The cache simply was not available. It was not injected. And I am more and more convinced that it is a bug, because sometimes it happens to Wildfly itself and the internal clustering stops to work. We then get the same error messages as were described e.g. here (ISPN000196: Failed to recover cluster state after the current node became the coordinator CacheNotFoundResponse)..

We would like to use Infinispan due to its distributed cache, hence normal maps won't help.

ad 3) <resource-env-ref/> was really just a desperate attempt when @Resource didn't work. We simply tried to force infinispan to provide the cache anyhow.

ad 4) Again, I tried it with this as a module or with the regular org.hibernate.infinispan and others. Always the same.

I have spent incredible number of hours trying everything possible. This worked in Wildlfy 8 without any problem (I guess we were using EAGER start, but I think it worked in WF8 even as LAZY.

As I have written in the original post, the problem according to me is in that for some reason, sometimes the cache is not initialized/instantiated or at least it is not injected correctly. Sometimes (randomly) it works without any change of configuration, so it could perhaps have something to do with some timeouts or stuff like that.

I appreciate any help. Many thanks.

Tomas