[jboss-jira] [JBoss JIRA] (WFLY-7016) Wildfly 10.1 IllegalStateException when starting applications when getting a session in a listener

Matthew Casperson (JIRA) issues at jboss.org
Mon Aug 29 03:05:00 EDT 2016


    [ https://issues.jboss.org/browse/WFLY-7016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285134#comment-13285134 ] 

Matthew Casperson edited comment on WFLY-7016 at 8/29/16 3:04 AM:
------------------------------------------------------------------

It appears this bug is related to the transaction level. The following settings worked in WildFly 10. The long timeouts are because of some very slow services in development environments.

{code}
<subsystem xmlns="urn:jboss:domain:infinispan:4.0">
                ...
                <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
                    <distributed-cache name="dist" mode="SYNC" l1-lifespan="0" owners="2">
                        <locking isolation="REPEATABLE_READ" striping="false" acquire-timeout="310000"/>
                        <transaction mode="NON_XA" locking="PESSIMISTIC"/>
                        <file-store/>
                    </distributed-cache>

                    <distributed-cache name="concurrent" mode="SYNC" l1-lifespan="0" owners="2">
                        <file-store/>
                    </distributed-cache>
                </cache-container>
{code}

This same config leads to the exception shown above in WildFly 10.1. However, setting *<transaction mode="BATCH" locking="PESSIMISTIC"/>* appears to work in WildFly 10.1. We're doing some more testing to make sure this setting works, but it only took a few minutes for the NON_XA transaction mode to throw exceptions, so it is looking quite likely that this setting is the cause of the issue. 


was (Author: mcasperson):
It appears this bug is related to the transaction level. The following settings worked in WildFly 10. The long timeouts are because of some very slow services in development environments.

{code}
<subsystem xmlns="urn:jboss:domain:infinispan:4.0">
                ...
                <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
                        <locking isolation="REPEATABLE_READ" striping="false" acquire-timeout="310000"/>
                        <transaction mode="NON_XA" locking="PESSIMISTIC"/>
                        <file-store/>
                    </distributed-cache>

                    <distributed-cache name="concurrent" mode="SYNC" l1-lifespan="0" owners="2">
                        <file-store/>
                    </distributed-cache>
                </cache-container>
{code}

This same config leads to the exception shown above in WildFly 10.1. However, setting *<transaction mode="BATCH" locking="PESSIMISTIC"/>* appears to work in WildFly 10.1. We're doing some more testing to make sure this setting works, but it only took a few minutes for the NON_XA transaction mode to throw exceptions, so it is looking quite likely that this setting is the cause of the issue. 

> Wildfly 10.1 IllegalStateException when starting applications when getting a session in a listener 
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7016
>                 URL: https://issues.jboss.org/browse/WFLY-7016
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 10.1.0.Final
>            Reporter: Matthew Casperson
>            Assignee: Stuart Douglas
>
> We have the following code in a ServletRequestListener:
> {code}
> final HttpSession httpSession = httpRequest.getSession(false);
> {code}
> This code is the line:
> {code}
> [Server:main-server] 	at au.com.agic.settings.listener.SessionInvalidatorListener.clearSession(SessionInvalidatorListener.java:94)
> {code}
> in the stack trace below.
> We have been running applications with this listener in WildFly 10 for months without any issues, but when we migrated to WildFly 10.1, Infinispan started throwing exceptions when opening the app for the first time. The exception doesn't always happen, but often enough to make WildFly 10.1 unusable.
> The configuration was copied directly from WildFly 10 to WildFly 10.1, so there are no configuration changes between the two versions.
> {code}
> [Server:main-server] 2016-08-26 15:03:10+1000 ERROR [[io.undertow.request]] [[default task-32]] UT005023: Exception handling request to /app/retrieve_quote.jsp: java.lang.IllegalStateException: Transaction TransactionImple < ac, BasicAction: 0:ffff0a1617d4:6cdfa442:57bfb3cd:31b status: ActionStatus.COMMITTED > is not in a valid state to be invoking cache operations on.
> [Server:main-server] 	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
> [Server:main-server] 	at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:351)
> [Server:main-server] 	at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> [Server:main-server] 	at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:331)
> [Server:main-server] 	at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [Server:main-server] 	at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [Server:main-server] 	at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] 	at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:177)
> [Server:main-server] 	at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:154)
> [Server:main-server] 	at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114)
> [Server:main-server] 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83)
> [Server:main-server] 	at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [Server:main-server] 	at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [Server:main-server] 	at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [Server:main-server] 	at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
> [Server:main-server] 	at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> [Server:main-server] 	at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403)
> [Server:main-server] 	at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> [Server:main-server] 	at org.wildfly.clustering.server.registry.CacheRegistry.getEntry(CacheRegistry.java:128)
> [Server:main-server] 	at org.wildfly.clustering.web.infinispan.session.InfinispanRouteLocator.locate(InfinispanRouteLocator.java:58)
> [Server:main-server] 	at org.wildfly.clustering.web.undertow.session.DistributableSessionIdentifierCodec.encode(DistributableSessionIdentifierCodec.java:48)
> [Server:main-server] 	at org.wildfly.extension.undertow.session.CodecSessionConfig.findSessionId(CodecSessionConfig.java:60)
> [Server:main-server] 	at io.undertow.servlet.spec.ServletContextImpl$ServletContextSessionConfig.findSessionId(ServletContextImpl.java:1084)
> [Server:main-server] 	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:778)
> [Server:main-server] 	at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:370)
> [Server:main-server] 	at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:375)
> [Server:main-server] 	at au.com.agic.settings.listener.SessionInvalidatorListener.clearSession(SessionInvalidatorListener.java:94)
> [Server:main-server] 	at au.com.agic.settings.listener.SessionInvalidatorListener.requestInitialized(SessionInvalidatorListener.java:52)
> [Server:main-server] 	at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246)
> [Server:main-server] 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:291)
> [Server:main-server] 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> [Server:main-server] 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> [Server:main-server] 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> [Server:main-server] 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> [Server:main-server] 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> [Server:main-server] 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> [Server:main-server] 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [Server:main-server] 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> [Server:main-server] 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> [Server:main-server] 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
> [Server:main-server] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] 	at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


More information about the jboss-jira mailing list