[JBoss JIRA] (WFLY-7016) Wildfly 10.1 now crashes when starting applications when getting a session in a listener
by Matthew Casperson (JIRA)
[ https://issues.jboss.org/browse/WFLY-7016?page=com.atlassian.jira.plugin.... ]
Matthew Casperson updated WFLY-7016:
------------------------------------
Description:
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. 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}
was:
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. 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}
> Wildfly 10.1 now crashes 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: Feature Request
> Components: 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. 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)
9 years, 2 months
[JBoss JIRA] (WFLY-6133) Add --connection-properties to datasource add command
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-6133?page=com.atlassian.jira.plugin.... ]
Lin Gao updated WFLY-6133:
--------------------------
Labels: downstream_dependency (was: )
> Add --connection-properties to datasource add command
> -----------------------------------------------------
>
> Key: WFLY-6133
> URL: https://issues.jboss.org/browse/WFLY-6133
> Project: WildFly
> Issue Type: Task
> Components: CLI, JCA
> Reporter: Alexey Loubyansky
> Assignee: Lin Gao
> Labels: downstream_dependency
>
> It isn't possible to add connection-properties using {{datasource add}} command. They can be added after the DS is created by directly working on {{/subsystem=datasources/data-source=XX/connection-properties}}
> It would be nice to have parameter --connection-properties in datasource add command. It could work the same way as {{xa-data-source add --name=DS --xa-datasource-properties=}}
> After WFCORE-1362 has been merged, a test for it has to be added to org.jboss.as.test.integration.management.cli.DataSourceTestCase.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-6200) connection-url is required even when not used
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-6200?page=com.atlassian.jira.plugin.... ]
Lin Gao updated WFLY-6200:
--------------------------
Labels: downstream_dependency (was: )
> connection-url is required even when not used
> ---------------------------------------------
>
> Key: WFLY-6200
> URL: https://issues.jboss.org/browse/WFLY-6200
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Lin Gao
> Labels: downstream_dependency
>
> Per the comments on WFLY-6157 and WFLY-6198, connection-url is ignored in a datasource if datasource-class is defined. However, connection-url is currently mandatory. If it is not present, WildFly fails to start:
> {noformat}
> 09:51:18,216 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 8) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "GamingPortalDS")
> ]) - failure description: "WFLYCTL0155: connection-url may not be null"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-7015) connection-url is required even when not used
by Lin Gao (JIRA)
Lin Gao created WFLY-7015:
-----------------------------
Summary: connection-url is required even when not used
Key: WFLY-7015
URL: https://issues.jboss.org/browse/WFLY-7015
Project: WildFly
Issue Type: Bug
Components: JCA
Affects Versions: 10.0.0.Final
Reporter: Lin Gao
Assignee: Lin Gao
Per the comments on WFLY-6157 and WFLY-6198, connection-url is ignored in a datasource if datasource-class is defined. However, connection-url is currently mandatory. If it is not present, WildFly fails to start:
{noformat}
09:51:18,216 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 8) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "GamingPortalDS")
]) - failure description: "WFLYCTL0155: connection-url may not be null"
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1715) HostProcessReloadHandler does not reset the HostRunningModeControl's restartMode
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1715?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1715:
------------------------------------------
{code}
It seems that the RestartMode has already a default value, created in the constructor of HostRunningModeControl. It's initialized to RestartMode.SERVERS in a single point: HostControllerEnvironment L298.
{code}
Ah, good, I missed that the field is set in the constructor method. Some test fixtures set it to HC_ONLY, but the production code sets SERVERS.
{code}
Whit the change in this issue, reverting RestartMode to its default after a HC reload, the sequence of actions of shutdown operation after a reload (with restart-servers true or false) will be the same and will be the sequences on case 2.
{code}
That's good. The case 2 sequence is better.
Thanks for the investigation.
> HostProcessReloadHandler does not reset the HostRunningModeControl's restartMode
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1715
> URL: https://issues.jboss.org/browse/WFCORE-1715
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.2.0.Final, 3.0.0.Alpha5
> Reporter: Yeray Santana Borges
> Assignee: Yeray Santana Borges
> Fix For: 3.0.0.Alpha6
>
>
> The ReloadContext created by HostProcessReloadHandler sets the HostRunningModeControl's restartMode but then it never gets restored to the default value. The doReload() method of the ReloadContext should restore it. This ensures the ServerInventoryService.stop() only uses the value set by HostProcessReloadHandler once, for that one reload.
> A concern here is that ServerInventoryService only goes into its "shutdownServers" logic if the restartMode == RestartMode.SERVERS. Which, due to this bug, it will be following any HC reload. But if we restore the default value of restartMode, that is null, and null != RestartMode.SERVERS. So the ""shutdownServers" logic will no longer kick in. But should it? Should the default value of restartMode be "null"? Or should it be RestartMode.SERVERS? If we change the default from null, then the behavior when no reload has happened will change.
> Basically we need to decide whether the "shutdownServers" logic should happen by default.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1715) HostProcessReloadHandler does not reset the HostRunningModeControl's restartMode
by Yeray Santana Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1715?page=com.atlassian.jira.plugi... ]
Yeray Santana Borges commented on WFCORE-1715:
----------------------------------------------
I have arrived to these conclusions after taking a look to the code around this issue:
# It seems that the RestartMode has already a default value, created in the constructor of HostRunningModeControl. It's initialized to RestartMode.SERVERS in a single point: HostControllerEnvironment L298. Its setter is only invoked in HostProcessReloadHandler#reloadInitiated L145 so it seems that currently the default value used is RestartMode.SERVERS.
# The possible "problem" could be if the user executes a reload(restartServers=false), this operation will let the HostRunningModeControl.RestartMode equals to RestartMode.HC_ONLY because it's never reverted to its default RestartMode.SERVERS after reloading the HC. The consequence I has been able to see is a minor different order when shutdown operation is executed after HC reload:
Case 1:
/host=master:reload(restart-servers=false)
/host=master:shutdown(restart=true)
Case 2:
/host=master:reload(restart-servers=true)
/host=master:shutdown(restart=true)
Shutdown op on case 1, servers are unregistered from the HC, the HC is stopped and at the end the server are stopped.
Shutdown op on case 2, servers are unregistered from HC, servers are stopped and at the end the HC is stopped.
Whit the change in this issue, reverting RestartMode to its default after a HC reload, the sequence of actions of shutdown operation after a reload (with restart-servers true or false) will be the same and will be the sequences on case 2.
[~brian.stansberry] About the default timeout, yes, I can confirm that it will be by default is 0 (code about timeout is in WFCORE-1427)
> HostProcessReloadHandler does not reset the HostRunningModeControl's restartMode
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1715
> URL: https://issues.jboss.org/browse/WFCORE-1715
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.2.0.Final, 3.0.0.Alpha5
> Reporter: Yeray Santana Borges
> Assignee: Yeray Santana Borges
> Fix For: 3.0.0.Alpha6
>
>
> The ReloadContext created by HostProcessReloadHandler sets the HostRunningModeControl's restartMode but then it never gets restored to the default value. The doReload() method of the ReloadContext should restore it. This ensures the ServerInventoryService.stop() only uses the value set by HostProcessReloadHandler once, for that one reload.
> A concern here is that ServerInventoryService only goes into its "shutdownServers" logic if the restartMode == RestartMode.SERVERS. Which, due to this bug, it will be following any HC reload. But if we restore the default value of restartMode, that is null, and null != RestartMode.SERVERS. So the ""shutdownServers" logic will no longer kick in. But should it? Should the default value of restartMode be "null"? Or should it be RestartMode.SERVERS? If we change the default from null, then the behavior when no reload has happened will change.
> Basically we need to decide whether the "shutdownServers" logic should happen by default.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1715) HostProcessReloadHandler does not reset the HostRunningModeControl's restartMode
by Yeray Santana Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1715?page=com.atlassian.jira.plugi... ]
Yeray Santana Borges reassigned WFCORE-1715:
--------------------------------------------
Assignee: Yeray Santana Borges
> HostProcessReloadHandler does not reset the HostRunningModeControl's restartMode
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1715
> URL: https://issues.jboss.org/browse/WFCORE-1715
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.2.0.Final, 3.0.0.Alpha5
> Reporter: Yeray Santana Borges
> Assignee: Yeray Santana Borges
> Fix For: 3.0.0.Alpha6
>
>
> The ReloadContext created by HostProcessReloadHandler sets the HostRunningModeControl's restartMode but then it never gets restored to the default value. The doReload() method of the ReloadContext should restore it. This ensures the ServerInventoryService.stop() only uses the value set by HostProcessReloadHandler once, for that one reload.
> A concern here is that ServerInventoryService only goes into its "shutdownServers" logic if the restartMode == RestartMode.SERVERS. Which, due to this bug, it will be following any HC reload. But if we restore the default value of restartMode, that is null, and null != RestartMode.SERVERS. So the ""shutdownServers" logic will no longer kick in. But should it? Should the default value of restartMode be "null"? Or should it be RestartMode.SERVERS? If we change the default from null, then the behavior when no reload has happened will change.
> Basically we need to decide whether the "shutdownServers" logic should happen by default.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1737) rrd on data-source=*/statistics=pool throws NPE
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1737?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1737:
------------------------------------------
I moved this to core, as the NPE is definitely in kernel logic and poking around in how the DS subsystem responds to requests there's nothing that seems amiss there.
> rrd on data-source=*/statistics=pool throws NPE
> -----------------------------------------------
>
> Key: WFCORE-1737
> URL: https://issues.jboss.org/browse/WFCORE-1737
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Claudio Miranda
> Assignee: Brian Stansberry
>
> Run the following command in CLI it throws a NullPointerException
> As it is a rrd it should not require a resolved wildcard
> {code}
> /subsystem=datasources/data-source=*/statistics=pool:read-resource-description
> {code}
> Results
> {code}
> {
> "outcome" => "failed",
> "result" => [],
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
> "rolled-back" => true
> }
> {code}
> The exception throws at server.log
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("resolve") failed - address: ([]): java.lang.NullPointerException
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:422)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeSingleTargetChild(GlobalOperationHandlers.java:903)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:442)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeMultiTargetChildren(GlobalOperationHandlers.java:895)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:440)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeSingleTargetChild(GlobalOperationHandlers.java:903)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:442)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:337)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> {code}
> This op works
> {code}
> /subsystem=datasources/data-source=*:read-resource-description
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1737) rrd on data-source=*/statistics=pool throws NPE
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1737?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-7013 to WFCORE-1737:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1737 (was: WFLY-7013)
Component/s: Domain Management
(was: Domain Management)
> rrd on data-source=*/statistics=pool throws NPE
> -----------------------------------------------
>
> Key: WFCORE-1737
> URL: https://issues.jboss.org/browse/WFCORE-1737
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Claudio Miranda
> Assignee: Brian Stansberry
>
> Run the following command in CLI it throws a NullPointerException
> As it is a rrd it should not require a resolved wildcard
> {code}
> /subsystem=datasources/data-source=*/statistics=pool:read-resource-description
> {code}
> Results
> {code}
> {
> "outcome" => "failed",
> "result" => [],
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
> "rolled-back" => true
> }
> {code}
> The exception throws at server.log
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("resolve") failed - address: ([]): java.lang.NullPointerException
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:422)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeSingleTargetChild(GlobalOperationHandlers.java:903)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:442)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeMultiTargetChildren(GlobalOperationHandlers.java:895)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:440)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeSingleTargetChild(GlobalOperationHandlers.java:903)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:442)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:337)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> {code}
> This op works
> {code}
> /subsystem=datasources/data-source=*:read-resource-description
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months