Deploying Web Application on wildfly 8.2-final getting java.la ng.IllegalStateException: Transaction DummyTransaction{xid=DummyXid is not in a valid state to be invoking cache operations on.

[sanjay05222]

I have deployed a war file and I see below error, I can see the index page of the web application but beyond that nothing happens and the error is thrown on the console as below.

I have seen other conversation where they had similar issue being discussed but looks like that there was a code change and I assume that had been resolved but I am afraid to say that It doesnt seem to me or I am doing some error in the my configuration.

Deployment : 8.2.0-Final Version  - Doesn't Work .

Deployment in 7.1.1 It Does Work

I am using a simple standalone configuration by default.  please suggest some solutions.

Other References :

Forum  https://developer.jboss.org/thread/249822?start=0&tstart=0

JIRA https://issues.jboss.org/i#browse/WFLY-4067

-----------------Error Stack ---------------

        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.

Final]

        at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]

        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_71]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_71]

        at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_71]

18:51:07,352 ERROR [io.undertow.request] (default task-5) Undertow request failed HttpServerExchange{ POST /SampleApplication/eventAction.do}: java.la

1. ng.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=62}, status=1} is not in a valid state to be invoking cache operations on.

        at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275)

        at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231)

        at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225)

        at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221)

        at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)

        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)

        at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)

        at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)

        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)

        at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)

        at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)

        at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)

        at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)

        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)

        at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)

        at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)

        at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)

        at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)

        at org.infinispan.CacheImpl.get(CacheImpl.java:377)

        at org.infinispan.DecoratedCache.get(DecoratedCache.java:396)

        at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271)

        at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54)

        at org.jboss.as.clustering.infinispan.invoker.Locator$LockingFindOperation.invoke(Locator.java:71)

          at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)

[sanjay05222]

Hi Guys , I was able to resolve this issue , I kind of not sure of exact reason but looks like that in war files which I was deploying which had web.xml  had an attributes <distributable> which actually not liked by undertow and infinspan. I will be trying to find the why this attribute affects and throws the error as above though . But thought of leaving the answer here so that people dont get misslead. looks like that the other issues earlier which I saw which were infact fixed and their jira showing resolved status makes it feel that there is no much issues with infinspan and undertow.  Further if the developers directly know out of there mind why this will conflict with the deployment on wildfly but work on Jboss7.1.1 version with out any issue that it would be so great. -- Thanks.

[pferraro]

Are you using javax.servlet.AsyncContext by any chance?

If so, see [WFLY-3715] Async servlets cause lock timeouts for distributable sessions - JBoss Issue Tracker

[sanjay05222]

Yes I am using DOJO and Struts api as this is totally a new application and I dont even have access to the code base yet just deploying the wars. I can say with surety application for sure might be using AyncContext for sure.  First of All thanks for looking at the issue and guiding me to the right places.

If i read and try to understand the WFLY-3715 I believe I have to configure the web configuration similar to the ejb one which comes by default out of the box in wildfly is that correct understanding.

I am going to try now and let you know the update .

config looks like below

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

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

                <local-cache name="passivation" batching="true">

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

                </local-cache>

                <local-cache name="persistent" batching="true">

                    <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" batching="true">

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

                </local-cache>

                <local-cache name="persistent" batching="true">

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

                </local-cache>

            </cache-container>

Thanks

Sanjay Gautam

[grkjava]

Hi,

After removing <distributable> tag from web.xml, i'm not getting TimedOutException on 8.1.0.Final.

Is this fix correct (or) any side effects?

Best Regards,

Ravi Kumar

[ctomc]

<distributable /> tag in web.xml enables/disables clustering

aka it tells app server if application should be clusterable (distributable) or not.

[sanjay05222]

Yes Tomaz is correct about the importance of that attribute in the web.xml. , Paul shared a JIRA and it is hard for me to infer what steps actually needs to be done to over come the issue and still the application remains distribute able and we dont get the timeout exception as well. I would have to read more about clustering configuration and see if I can find some solution though. web dtd or xsd provides the info about that attribute.

With that question comes it that will WILDFLY depend on that attribute or if we have cluster and we deploy the app in cluster probably it will distribute it in both the servers in the cluster is that correct understanding. ?

[tomlux]

We also had problems with deployments where we got the DummyTransaction Exception.

Our applications are cluster-aware (distributable) and the WildFly is version 8.2

After replacing the infinispan-core-6.0.2 library in the modules with the infinispan-core-6.0.3-SNAPSHOT, everything is working as expected.

We can do redeployments without any DummyTransaction-Exception.

Tom

[sanjay05222]

Thanks for additional information @Tom I tried to look into the Jboss Repository and Infinispan downloads also , But I could not find the infinispan-core-6.0.3-SNAPSHOT.

Please let me know from where you got the right snapshot. I dont want to upgrade to the latest 7.0.2-final version right now.  Please share the information . - Thanks

[tomlux]

Hy,

I compiled it on myown.

This pull-request solved the problem:

[master] ISPN-4969 Stopping a cache will stop all KeyAffinityServices created for other caches in the cache manager by p…

Just check it out and use maven to compile this module:

https://github.com/infinispan/infinispan/blob/6.0.x/core/pom.xml

Take care to use the 6.0.x branch during your git checkout.

[sanjay05222]

Thanks Tom it was a great help , cause I tried the latest ones it kind of not working which is available on their site. I dont want to do significant changes in the wildfly modules.

Let me try to build just like you.

Thanks for helping me out with the details to get the snapshots.

Thanks

Sanjay

[sanjay05222]

I had this thought if you are well averse  with how the Open Source development works in this case wildfly. isnt it will be good if we can some how update the wildfly 8.2-Final release some way that we don't get this issue.

I just just thinking loud what about wildlfy 9.0.0 which is out there ? I have downloaded it and I will check I get the same issue in that version as well. it is just the matter of the module.

I am not sure what is the right way to pursue this so that it get fixed in the furture and present version as 9.0.0 also use the same one which was there in the wildfly 8.2.0

Thanks

Sanjay Gautam

[ctomc]

SANJAY GAUTAM wrote:

I had this thought if you are well averse  with how the Open Source development works in this case wildfly. isnt it will be good if we can some how update the wildfly 8.2-Final release some way that we don't get this issue.

I just just thinking loud what about wildlfy 9.0.0 which is out there ? I have downloaded it and I will check I get the same issue in that version as well. it is just the matter of the module.

I am not sure what is the right way to pursue this so that it get fixed in the furture and present version as 9.0.0 also use the same one which was there in the wildfly 8.2.0

Thanks

Sanjay Gautam

AFAIK this is fixed in master just not in 9.0.0.Alpha1 yet.

To make sure build master yourself or grab nightly build from https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/WildFly/job/WildFly-latest-master/

to verify.

[jaikiran]

Tomaz Cerar wrote:

or grab nightly build from https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/WildFly/job/WildFly-latest-master/

to verify.

I think Tomaz meant to point you to this WildFly nightly builds available Follow the instructions in that thread to get the latest nightly WildFly builds.

[tomlux]

Confirmation, this bug is already fixed in the nightly builds of the 9.0.x branch which uses the 7.0 branch of Infinispan.

Just download the latest master from this site: http://ci.jboss.org/hudson/job/WildFly-latest-master/

Tom