Wildfly | Infinispan Warning

[nick.sree]

We are getting the following warning in some regular interval, we are using wildfly 9.0.2, Is this something we have to worry about ? thanks in advance...

2015-12-16 14:02:07,849 WARN  [org.infinispan.transaction.tm.DummyTransaction] (SessionExpirationScheduler - 1)   ISPN000112: exception while committing: javax.transaction.xa.XAException

        at org.infinispan.transaction.xa.TransactionXaAdapter.getLocalTransactionAndValidateImpl(TransactionXaAdapter.java:239)

        at org.infinispan.transaction.xa.TransactionXaAdapter.getLocalTransactionAndValidate(TransactionXaAdapter.java:232)

        at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:101)

        at org.infinispan.transaction.tm.DummyTransaction.finishResource(DummyTransaction.java:367)

        at org.infinispan.transaction.tm.DummyTransaction.commitResources(DummyTransaction.java:413)

        at org.infinispan.transaction.tm.DummyTransaction.runCommit(DummyTransaction.java:303)

        at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:104)

        at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:73)

        at org.wildfly.clustering.ee.infinispan.ActiveTransactionBatch.close(ActiveTransactionBatch.java:48)

        at org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler$ExpirationTask.run(SessionExpirationScheduler.java:149)

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

        at java.util.concurrent.FutureTask.run(FutureTask.java:266)

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

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

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

        at org.jboss.threads.JBossThread.run(JBossThread.java:320)

[pferraro]

This exception indicates that a particular session is failing to expire - though I can't tell why exactly from this exception.

Can you reproduce using WildFly 10?

[nick.sree]

We are using wildfly 9.0.2 Final do you mean to try with 10.0.0.CR4 ?

Sorry if i not understand it fully, why wildfly is using infinispan to handle session ? though my web.xml does'nt contain <distributable/> ?, we have a EAR deployment, does something to do with that ?

[pferraro]

Nick . wrote:

We are using wildfly 9.0.2 Final do you mean to try with 10.0.0.CR4 ?

Yes.

Nick . wrote:

Sorry if i not understand it fully, why wildfly is using infinispan to handle session ? though my web.xml does'nt contain <distributable/> ?, we have a EAR deployment, does something to do with that ?

Your web sessions would only use Infinispan if <distributable/>.  My guess is that these exceptions happen with your @Stateful EJBs.  @Stateful EJBs will use Infinispan by default, unless configured as @Stateful(passivation-capable=false).

[nick.sree]

We are not using EJB's as well. even we have removed cache config for ejb and disabled EJB subsystem as well. In my local i couldn't replicate but in production system i can see that log, even both prod and local we are using same config and wildfly version, well let me see i can replicate locally, if so i can try with wildfly 10.

[pferraro]

Are you sure your web.xml doesn't contain <distributable/>?  Otherwise, unless you are using shared sessions (between WARs within an EAR), I can't see why the Infinispan-based session manager would be getting used.

wildfly/UndertowDeploymentProcessor.java at 9.x · wildfly/wildfly · GitHub

[nick.sree]

Pretty much sure about not using <distributable/> and yes we are using shared session for war

[nick.sree]

FYI, we are using shared-session-config.

[pferraro]

OK - that's helpful to know.  Currently, shared-session-config will use an Infinispan-based session manager if the modules for it are present.  You can either:

1. Try using WildFly 10.0.0.CR5.
2. Edit the module.xml descriptor for the org.wildfly.clustering.web.spi and remove the line that refers to the org.wildfly.clustering.web.infinispan module.
3. Remove the org.wildfly.clustering.web.infinispan module entirely from your distribution

[nick.sree]

Thanks pferraro, Does Infinispan-based session manager is disabled by default in Wildfly 10.x ? because i can see module.xml  descriptor for the org.wildfly.clustering.web.spi  is still using infinispan.

Does session sharing (shared-session-config) functionality will affect in anyway if i disable it ?

[pferraro]

Because the shared session configuration lacks a means for indicating whether it should be distributable, the Infinispan-based session manager is used by default (if the requisite modules are present).

See: [WFLY-5497] Add <distributable/> to shared-session-config schema - JBoss Issue Tracker

If you remove the org.wildfly.clustering.web.infinispan module, or remove the reference to it within org.wildfly.clustering.web.spi, then the in-memory session manager will be used instead.

[nick.sree]

Thanks pferraro for your immense support and helping to understand how does it work.

[nick.sree]

Hi pferraro i have tried removing as you have mentioned in the previous reply after that i'm getting the following error. This i have tried in Wildfly-10.0.0.Final

016-04-05 08:43:32,367 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 52)   WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "undertow")]): java.lang.NullPointerException

  at org.wildfly.clustering.web.undertow.session.DistributableSessionIdentifierCodecBuilder.buildServerDependency(DistributableSessionIdentifierCodecBuilder.java:84)

  at org.wildfly.extension.undertow.UndertowSubsystemAdd.performBoottime(UndertowSubsystemAdd.java:146)

  at org.jboss.as.controller.AbstractBoottimeAddStepHandler.performRuntime(AbstractBoottimeAddStepHandler.java:116)

  at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)

  at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)

  at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)

  at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)

  at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359)

  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

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

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

  at org.jboss.threads.JBossThread.run(JBossThread.java:320)

2016-04-05 08:43:32,382 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2)   WFLYUT0004: Undertow 1.3.15.Final stopping

2016-04-05 08:43:33,163 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 31)   WFLYJCA0005: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.4)

2016-04-05 08:43:33,171 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2)   WFLYJCA0018: Started Driver service with driver-name = postgres

2016-04-05 08:43:33,270 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread)   "WFLYCTL0193: Failed executing subsystem undertow boot operations"

2016-04-05 08:43:33,270 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread)   WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem undertow boot operations\""

[pferraro]

Additionally, you'll need to remove the dependency on "org.wildfly.clustering.web.undertow" from the "org.wildfly.extension.undertow" module.

[nick.sree]

pferraro thanks for this additional info, now i'm not getting any deployment error but except my login page all other page are giving 404 response, when i put back those setting then its working normally.