[JBoss JIRA] (WFLY-6703) Failover fails with WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-6703:
------------------------------------
Summary: Failover fails with WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
Key: WFLY-6703
URL: https://issues.jboss.org/browse/WFLY-6703
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Reporter: Radoslav Husar
Assignee: Stuart Douglas
13:57:41,855 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /clusterbench/session: org.jboss.weld.exceptions.IllegalStateException: WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
Expected hash: 1931672237
Current index: BeanIdentifierIndex [hash=1185198536, indexed=13]
0: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-ejb.jar%HttpSession
1: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-web-default.war%HttpSession
2: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-web-granular.war%HttpSession
3: WELD%AbstractBuiltInBean%/content/clusterbench-ee7.ear/clusterbench-ee7-web-passivating.war%HttpSession
4: WELD%AbstractBuiltInBean%clusterbench-ee7.ear%HttpSession
5: WELD%AbstractBuiltInBean%com.sun.jsf-impl:main.additionalClasses%HttpSession
6: WELD%AbstractBuiltInBean%org.hibernate.validator.cdi:main.additionalClasses%HttpSession
7: WELD%AbstractBuiltInBean%org.jberet.jberet-core:main.additionalClasses%HttpSession
8: WELD%AbstractBuiltInBean%org.jboss.as.jsf:main.additionalClasses%HttpSession
9: WELD%AbstractBuiltInBean%org.jboss.resteasy.resteasy-cdi:main.additionalClasses%HttpSession
10: WELD%ManagedBean%clusterbench-ee7.ear|/content/clusterbench-ee7.ear/clusterbench-ee7-web-default.war|org.jboss.test.clusterbench.web.cdi.SessionScopedCdiSerialBean|null|false
11: WELD%ManagedBean%clusterbench-ee7.ear|/content/clusterbench-ee7.ear/clusterbench-ee7-web-passivating.war|org.jboss.test.clusterbench.web.cdi.SessionScopedCdiSerialBean|null|false
12: WELD%SessionBean%LocalStatefulSB%org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB
at org.jboss.weld.context.http.HttpSessionContextImpl.checkBeanIdentifierIndexConsistency(HttpSessionContextImpl.java:101)
at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:47)
at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:23)
at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:237)
at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:245)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
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)
13:57:41,941 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel server: [node1|2] (1) [node1]
13:57:41,942 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel web: [node1|2] (1) [node1]
13:57:41,943 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel hibernate: [node1|2] (1) [node1]
13:57:41,944 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-6,ee,node1) ISPN000094: Received new cluster view for channel ejb: [node1|2] (1) [node1]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6696) Problem with infinispan, Unable to acquire lock after 15 seconds for key
by bruno silva (JIRA)
[ https://issues.jboss.org/browse/WFLY-6696?page=com.atlassian.jira.plugin.... ]
bruno silva updated WFLY-6696:
------------------------------
Description:
I have two nodes in cluster using standalone-ha.xml, but when put <distributable/> into web.xml the error below has happened frenquently and I'm using SSO.
{noformat}
2016-06-09 14:46:55,160 ERROR [io.undertow.request] (default task-93) UT005071: Undertow request failed HttpServerExchange{ GET /intranet/app/pagina.action request Cookie=[JSESSIONID=hwGOzICm6QQGaHzyf3MQ8jK8j7aRBGbDksNF4oeK.node3; JSESSIONIDSSO=iYEO1MGfzBBsKmvmuO8HPz0whseKXJmRzjuuuiRQ; org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key hwGOzICm6QQGaHzyf3MQ8jK8j7aRBGbDksNF4oeK and requestor GlobalTransaction:<node3>:475504:local. Lock is held by GlobalTransaction:<node3>:474447:local
at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAllAndRecord(AbstractLockingInterceptor.java:199)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:199)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:165)
at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:184)
at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:157)
at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:215)
at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:78)
at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:238)
at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:102)
at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:81)
at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:828)
at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:810)
at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.lock(AbstractDelegatingAdvancedCache.java:177)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:84)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:69)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:39)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:61)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:40)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:234)
at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:139)
at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:726)
at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:756)
at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:760)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:557)
at io.undertow.servlet.spec.HttpServletResponseImpl.doErrorDispatch(HttpServletResponseImpl.java:168)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:319)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
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)
{noformat}
was:
I have two nodes in cluster using standalone-ha.xml, but when put <distributable/> into web.xml the error below has happened frenquently.
{noformat}
2016-06-09 14:46:55,160 ERROR [io.undertow.request] (default task-93) UT005071: Undertow request failed HttpServerExchange{ GET /intranet/app/pagina.action request Cookie=[JSESSIONID=hwGOzICm6QQGaHzyf3MQ8jK8j7aRBGbDksNF4oeK.node3; JSESSIONIDSSO=iYEO1MGfzBBsKmvmuO8HPz0whseKXJmRzjuuuiRQ; org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key hwGOzICm6QQGaHzyf3MQ8jK8j7aRBGbDksNF4oeK and requestor GlobalTransaction:<node3>:475504:local. Lock is held by GlobalTransaction:<node3>:474447:local
at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAllAndRecord(AbstractLockingInterceptor.java:199)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:199)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:165)
at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:184)
at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:157)
at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:215)
at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:78)
at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:238)
at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:102)
at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:81)
at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:828)
at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:810)
at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.lock(AbstractDelegatingAdvancedCache.java:177)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:84)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:69)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:39)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:61)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:40)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:234)
at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:139)
at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:726)
at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:756)
at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:760)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:557)
at io.undertow.servlet.spec.HttpServletResponseImpl.doErrorDispatch(HttpServletResponseImpl.java:168)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:319)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
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)
{noformat}
> Problem with infinispan, Unable to acquire lock after 15 seconds for key
> -------------------------------------------------------------------------
>
> Key: WFLY-6696
> URL: https://issues.jboss.org/browse/WFLY-6696
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: linux debian, apache, oracle database
> Reporter: bruno silva
> Assignee: Paul Ferraro
> Attachments: error.txt
>
>
> I have two nodes in cluster using standalone-ha.xml, but when put <distributable/> into web.xml the error below has happened frenquently and I'm using SSO.
> {noformat}
> 2016-06-09 14:46:55,160 ERROR [io.undertow.request] (default task-93) UT005071: Undertow request failed HttpServerExchange{ GET /intranet/app/pagina.action request Cookie=[JSESSIONID=hwGOzICm6QQGaHzyf3MQ8jK8j7aRBGbDksNF4oeK.node3; JSESSIONIDSSO=iYEO1MGfzBBsKmvmuO8HPz0whseKXJmRzjuuuiRQ; org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key hwGOzICm6QQGaHzyf3MQ8jK8j7aRBGbDksNF4oeK and requestor GlobalTransaction:<node3>:475504:local. Lock is held by GlobalTransaction:<node3>:474447:local
> at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAllAndRecord(AbstractLockingInterceptor.java:199)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:199)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:165)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:184)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:157)
> at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:215)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:78)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:238)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:102)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:81)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:828)
> at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:810)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.lock(AbstractDelegatingAdvancedCache.java:177)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:84)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:69)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:39)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:61)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:40)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:234)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:139)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:726)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:756)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:760)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:557)
> at io.undertow.servlet.spec.HttpServletResponseImpl.doErrorDispatch(HttpServletResponseImpl.java:168)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:319)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-2859) Treating all JAX-RS components as CDI Beans has some negative consequences
by Matt Drees (JIRA)
[ https://issues.jboss.org/browse/WFLY-2859?page=com.atlassian.jira.plugin.... ]
Matt Drees commented on WFLY-2859:
----------------------------------
Hey [~swd847] I'm bumping into this again. (After initially trying to port my app from jboss 7.1 to wildfly 8 a few years ago and failing, I'm now trying again to port it, but to wildfly 10 now).
I'm sad that your change was backed out. So I'm wondering about other ways to fix this.
Would it be reasonable to change Resteasy such that, instead of always adding the Application scope annotation to the provider's AnnotatedType, it chose either Dependent or Application, depending on whether the class was proxyable?
If so I'd be happy to contribute that.
> Treating all JAX-RS components as CDI Beans has some negative consequences
> --------------------------------------------------------------------------
>
> Key: WFLY-2859
> URL: https://issues.jboss.org/browse/WFLY-2859
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, REST
> Affects Versions: 8.0.0.CR1
> Reporter: Matt Drees
> Assignee: Stuart Douglas
>
> It seems that wildfly is now treating all jax-rs Providers and Resources as CDI Beans. This is probably fine most of the time, but there are some Provider classes that cause UnproxyableResolutionException (WELD-001437) errors, due to the fact that resteasy-cdi attempts to get bean reference whose type is identical to the bean class.
> See the forum link for a specific instance of this.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6702) Infinispan Singleton silently dies in wildfly 9 cluster setup
by Divey Gupta (JIRA)
[ https://issues.jboss.org/browse/WFLY-6702?page=com.atlassian.jira.plugin.... ]
Divey Gupta updated WFLY-6702:
------------------------------
Affects Version/s: 9.0.1.Final
(was: 9.0.2.Final)
> Infinispan Singleton silently dies in wildfly 9 cluster setup
> -------------------------------------------------------------
>
> Key: WFLY-6702
> URL: https://issues.jboss.org/browse/WFLY-6702
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.1.Final
> Environment: linux,64gb RAM
> Reporter: Divey Gupta
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: cluster, infinispan, singleton, wildfly
>
> I am using wildfly 9 in a cluster setup of 3 nodes (standalone-full-ha.xml) and use Singleton service for some of our operations. Sometimes (during heavy load/traffic) we are seeing that singleton service silently dies without giving any error or exception. There was no exception like : "Failed to get quorum.."
> When load reduces (number of concurrent requests) on wildfly, then also it doesn't recover i.e. reactivate singleton in some node. In order to start singleton again, the only option that works is manually restarting wildfly
> Following is my standalone-full-ha.xml config for infinispan and Jgroups.
> <stack name="tcp">
> <transport socket-binding="jgroups-tcp" type="TCP"/>
> <protocol type="TCPPING">
> <property name="initial_hosts">
> 10.0.1.32[7600],10.0.1.38[7600],10.0.1.39[7600]</property>
> <property name="port_range">
> 0
> </property>
> </protocol>
> <protocol type="MERGE2"/>
> <protocol socket-binding="jgroups-tcp-fd" type="FD_SOCK"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS">
> <property name="join_timeout">
> 5000
> </property>
> </protocol>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> ....
> <subsystem xmlns="urn:jboss:domain:infinispan:3.0">
> <cache-container aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server" name="server">
> <transport lock-timeout="120000"/>
> <replicated-cache mode="ASYNC" name="default">
> <state-transfer enabled="true" timeout="300000"/>
> <transaction locking="OPTIMISTIC" mode="BATCH"/>
> </replicated-cache>
> </cache-container>
> <cache-container default-cache="session" module="org.wildfly.clustering.web.infinispan" name="web">
> <transport lock-timeout="120000"/>
> <replicated-cache mode="ASYNC" name="session">
> <state-transfer enabled="true" timeout="300000"/>
> <locking isolation="READ_COMMITTED"/>
> <transaction locking="OPTIMISTIC" mode="BATCH"/>
> </replicated-cache>
> </cache-container>
> </subsystem>
> Following is a java code snippet that we use to activate and start singleton in a cluster:
> public class SingletonServiceActivator implements ServiceActivator {
> public static final ServiceName SINGLETON_SERVICE_NAME =
> ServiceName.JBOSS.append("ha", "singleton");
> private static final String CONTAINER_NAME = "server";
> private static final String CACHE_NAME = "default";
> @Override
> public void activate(ServiceActivatorContext context) throws ServiceRegistryException {
> int quorum = 2;
> InjectedValue<ServerEnvironment> env = new InjectedValue<>();
> SingletonServiceClient srv = new SingletonServiceClient(env);
> ServiceController<?> factoryService = context.getServiceRegistry().getRequiredService(SingletonServiceBuilderFactory.SERVICE_NAME.append(CONTAINER_NAME, CACHE_NAME));
> SingletonServiceBuilderFactory factory = (SingletonServiceBuilderFactory) factoryService.getValue();
> SingletonElectionPolicy policy = new SimpleSingletonElectionPolicy(0);
> factory.createSingletonServiceBuilder(SINGLETON_SERVICE_NAME, srv)
> .requireQuorum(quorum)
> .electionPolicy(policy)
> .build(new DelegatingServiceContainer(context.getServiceTarget(),context.getServiceRegistry()))
> .addDependency(ServerEnvironmentService.SERVICE_NAME, ServerEnvironment.class, env)
> .setInitialMode(ServiceController.Mode.ACTIVE)
> .install();
> }
> public final class SingletonServiceClient extends AbstractService<Serializable> {
> private final Value<ServerEnvironment> env;
> public SingletonServiceClient(Value<ServerEnvironment> env) {
> this.env = env;
> }
> @Override
> public void start(StartContext startContext) {
> // startContext.
> log("SingletonService started");
> //do work
> }
> @Override
> public void stop(StopContext stopContext) {
> log("SingletonService stopped"); // THIS NEVER GETS CALLED
> //stop
> }
> }
> Is there something wrong in the config or in the way I am trying to activate and start singleton ?
> I thought that there could be some connectivity issue between nodes in a cluster because of which its unable to get desired quorum to start singleton. Just to experiment, I changed quorum to 1. But still sometimes I see this issue during heavy load.
> I will really appreciate some help or suggestions on this issue.
> Also, is there a way to monitor state of singleton from application code and trigger it from our application code ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6702) Infinispan Singleton silently dies in wildfly 9 cluster setup
by Divey Gupta (JIRA)
Divey Gupta created WFLY-6702:
---------------------------------
Summary: Infinispan Singleton silently dies in wildfly 9 cluster setup
Key: WFLY-6702
URL: https://issues.jboss.org/browse/WFLY-6702
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 9.0.2.Final
Environment: linux,64gb RAM
Reporter: Divey Gupta
Assignee: Paul Ferraro
Priority: Blocker
I am using wildfly 9 in a cluster setup of 3 nodes (standalone-full-ha.xml) and use Singleton service for some of our operations. Sometimes (during heavy load/traffic) we are seeing that singleton service silently dies without giving any error or exception. There was no exception like : "Failed to get quorum.."
When load reduces (number of concurrent requests) on wildfly, then also it doesn't recover i.e. reactivate singleton in some node. In order to start singleton again, the only option that works is manually restarting wildfly
Following is my standalone-full-ha.xml config for infinispan and Jgroups.
<stack name="tcp">
<transport socket-binding="jgroups-tcp" type="TCP"/>
<protocol type="TCPPING">
<property name="initial_hosts">
10.0.1.32[7600],10.0.1.38[7600],10.0.1.39[7600]</property>
<property name="port_range">
0
</property>
</protocol>
<protocol type="MERGE2"/>
<protocol socket-binding="jgroups-tcp-fd" type="FD_SOCK"/>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS">
<property name="join_timeout">
5000
</property>
</protocol>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
<protocol type="RSVP"/>
</stack>
....
<subsystem xmlns="urn:jboss:domain:infinispan:3.0">
<cache-container aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server" name="server">
<transport lock-timeout="120000"/>
<replicated-cache mode="ASYNC" name="default">
<state-transfer enabled="true" timeout="300000"/>
<transaction locking="OPTIMISTIC" mode="BATCH"/>
</replicated-cache>
</cache-container>
<cache-container default-cache="session" module="org.wildfly.clustering.web.infinispan" name="web">
<transport lock-timeout="120000"/>
<replicated-cache mode="ASYNC" name="session">
<state-transfer enabled="true" timeout="300000"/>
<locking isolation="READ_COMMITTED"/>
<transaction locking="OPTIMISTIC" mode="BATCH"/>
</replicated-cache>
</cache-container>
</subsystem>
Following is a java code snippet that we use to activate and start singleton in a cluster:
public class SingletonServiceActivator implements ServiceActivator {
public static final ServiceName SINGLETON_SERVICE_NAME =
ServiceName.JBOSS.append("ha", "singleton");
private static final String CONTAINER_NAME = "server";
private static final String CACHE_NAME = "default";
@Override
public void activate(ServiceActivatorContext context) throws ServiceRegistryException {
int quorum = 2;
InjectedValue<ServerEnvironment> env = new InjectedValue<>();
SingletonServiceClient srv = new SingletonServiceClient(env);
ServiceController<?> factoryService = context.getServiceRegistry().getRequiredService(SingletonServiceBuilderFactory.SERVICE_NAME.append(CONTAINER_NAME, CACHE_NAME));
SingletonServiceBuilderFactory factory = (SingletonServiceBuilderFactory) factoryService.getValue();
SingletonElectionPolicy policy = new SimpleSingletonElectionPolicy(0);
factory.createSingletonServiceBuilder(SINGLETON_SERVICE_NAME, srv)
.requireQuorum(quorum)
.electionPolicy(policy)
.build(new DelegatingServiceContainer(context.getServiceTarget(),context.getServiceRegistry()))
.addDependency(ServerEnvironmentService.SERVICE_NAME, ServerEnvironment.class, env)
.setInitialMode(ServiceController.Mode.ACTIVE)
.install();
}
public final class SingletonServiceClient extends AbstractService<Serializable> {
private final Value<ServerEnvironment> env;
public SingletonServiceClient(Value<ServerEnvironment> env) {
this.env = env;
}
@Override
public void start(StartContext startContext) {
// startContext.
log("SingletonService started");
//do work
}
@Override
public void stop(StopContext stopContext) {
log("SingletonService stopped"); // THIS NEVER GETS CALLED
//stop
}
}
Is there something wrong in the config or in the way I am trying to activate and start singleton ?
I thought that there could be some connectivity issue between nodes in a cluster because of which its unable to get desired quorum to start singleton. Just to experiment, I changed quorum to 1. But still sometimes I see this issue during heavy load.
I will really appreciate some help or suggestions on this issue.
Also, is there a way to monitor state of singleton from application code and trigger it from our application code ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-3529) UT000010: Session not found
by Robert Smith (JIRA)
[ https://issues.jboss.org/browse/WFLY-3529?page=com.atlassian.jira.plugin.... ]
Robert Smith commented on WFLY-3529:
------------------------------------
We have seen the behaviour in Wildfly 9.0.2.Final. Would having a custom session id cause a problem? We see the error in domain mode in a consistent manner. We never see it in standalone mode, only domain mode.
> UT000010: Session not found
> ----------------------------
>
> Key: WFLY-3529
> URL: https://issues.jboss.org/browse/WFLY-3529
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Environment: Wildfly 8.1.0.Final ,
> Reporter: Youssef BIKHCHICHE
> Assignee: Stuart Douglas
> Fix For: 9.0.0.CR1
>
> Attachments: WFLY-3529.tar.gz, WFLY-3529.war
>
>
> After migration our AS from Woldfly 8.0.0 to 8.1.0 we get this issue that we think has been fixed in the previous release of wildfly.
> ERREOR code :
> 2014-06-20 12:45:21,092 ERROR [io.undertow.request] (default task-11) Blocking request failed HttpServerExchange{ GET /xenturion/faces/public/500.xhtml}: java.lang.RuntimeException: java.lang.IllegalStateException: UT000010: Session not found cX6YRwOmoXcB8FFUdNY2r7Te
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:408)
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:311)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:128)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.IllegalStateException: UT000010: Session not found cX6YRwOmoXcB8FFUdNY2r7Te
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:319)
> at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:121)
> at org.springframework.security.web.context.HttpSessionSecurityContextRepository.readSecurityContextFromSession(HttpSessionSecurityContextRepository.java:144)
> at org.springframework.security.web.context.HttpSessionSecurityContextRepository.loadContext(HttpSessionSecurityContextRepository.java:86)
> at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:82)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:343)
> at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:260)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:229)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:172)
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:402)
> ======================================================
> this issue happens after a http session invalidate action and it' not a regular problems.
> Best regards,
> Youssef
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6224) IllegalStateException "transaction is not in a valid state" during a 2clusters test
by bruno silva (JIRA)
[ https://issues.jboss.org/browse/WFLY-6224?page=com.atlassian.jira.plugin.... ]
bruno silva edited comment on WFLY-6224 at 6/10/16 2:51 PM:
------------------------------------------------------------
I have a similar problem, so I updated the files that you commited in the link above, but it did not work. The exception is following below:
{noformat}
2016-06-09 14:44:41,023 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (ServerService Thread Pool -- 101) ISPN000136: Error executing command KeySetCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=20235}, status=1} is not in a valid state to be invoking cache operations on.
at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:394)
at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:350)
at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:344)
at org.infinispan.interceptors.TxInterceptor.visitKeySetCommand(TxInterceptor.java:255)
at org.infinispan.interceptors.TxInterceptor.visitKeySetCommand(TxInterceptor.java:85)
at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:49)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:100)
at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:49)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:392)
at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:100)
at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:49)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:100)
at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:49)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:100)
at org.infinispan.interceptors.distribution.DistributionBulkInterceptor.visitKeySetCommand(DistributionBulkInterceptor.java:245)
at org.infinispan.interceptors.distribution.DistributionBulkInterceptor.visitKeySetCommand(DistributionBulkInterceptor.java:48)
at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:49)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
at org.infinispan.cache.impl.CacheImpl.keySet(CacheImpl.java:603)
at org.infinispan.cache.impl.DecoratedCache.keySet(DecoratedCache.java:478)
at org.infinispan.cache.impl.AbstractDelegatingCache.keySet(AbstractDelegatingCache.java:311)
at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.schedule(InfinispanBeanManager.java:329)
at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.start(InfinispanBeanManager.java:165)
at org.jboss.as.ejb3.cache.distributable.DistributableCache.start(DistributableCache.java:178)
at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.start(StatefulSessionComponent.java:341)
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
{noformat}
was (Author: bcampolina):
I have a similar problem, so I updated the files that you commited in the link above, but it did not work. The exception is following below:
2016-06-09 14:44:41,023 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (ServerService Thread Pool -- 101) ISPN000136: Error executing command KeySetCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=20235}, status=1} is not in a valid state to be invoking cache operations on.
at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:394)
at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:350)
at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:344)
at org.infinispan.interceptors.TxInterceptor.visitKeySetCommand(TxInterceptor.java:255)
at org.infinispan.interceptors.TxInterceptor.visitKeySetCommand(TxInterceptor.java:85)
at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:49)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:100)
at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:49)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:392)
at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:100)
at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:49)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:100)
at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:49)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:100)
at org.infinispan.interceptors.distribution.DistributionBulkInterceptor.visitKeySetCommand(DistributionBulkInterceptor.java:245)
at org.infinispan.interceptors.distribution.DistributionBulkInterceptor.visitKeySetCommand(DistributionBulkInterceptor.java:48)
at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:49)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
at org.infinispan.cache.impl.CacheImpl.keySet(CacheImpl.java:603)
at org.infinispan.cache.impl.DecoratedCache.keySet(DecoratedCache.java:478)
at org.infinispan.cache.impl.AbstractDelegatingCache.keySet(AbstractDelegatingCache.java:311)
at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.schedule(InfinispanBeanManager.java:329)
at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.start(InfinispanBeanManager.java:165)
at org.jboss.as.ejb3.cache.distributable.DistributableCache.start(DistributableCache.java:178)
at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.start(StatefulSessionComponent.java:341)
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
> IllegalStateException "transaction is not in a valid state" during a 2clusters test
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6224
> URL: https://issues.jboss.org/browse/WFLY-6224
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Paul Ferraro
> Fix For: 10.1.0.Final
>
>
> During a 2clusters test eap-7x-failover-ejb-2clusters-ejbremote-shutdown-repl-async (where 2clusters test = standalone EJB client -> 2-node "forwarder" cluster -> 2-node "target" cluster -> back to "forwarder" -> back to standalone client), I'm seeing {{IllegalStateException: Transaction is not in a valid state to be invoking cache operations on}}:
> {code}
> 05:12:09,813 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-40) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=352}, status=3} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:394)
> at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:350)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:344)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:176)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:153)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:85)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:49)
> at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:238)
> at org.jboss.as.ejb3.cache.distributable.DistributableCache.release(DistributableCache.java:137)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.releaseInstance(StatefulSessionSynchronizationInterceptor.java:168)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor$StatefulSessionSynchronization.afterCompletion(StatefulSessionSynchronizationInterceptor.java:250)
> at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.afterCompletion(JCAOrderedLastSynchronizationList.java:147)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:545)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:476)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.SubordinateAtomicAction.doOnePhaseCommit(SubordinateAtomicAction.java:247)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple.doOnePhaseCommit(TransactionImple.java:283)
> at org.jboss.as.ejb3.remote.protocol.versionone.XidTransactionCommitTask.manageTransaction(XidTransactionCommitTask.java:85)
> at org.jboss.as.ejb3.remote.protocol.versionone.XidTransactionManagementTask.run(XidTransactionManagementTask.java:68)
> at org.jboss.as.ejb3.remote.protocol.versionone.TransactionRequestHandler.processMessage(TransactionRequestHandler.java:139)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> 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)
> {code}
> The difference from WFLY-4678 is the circumstances.
> In the following text, I'm refering to the nodes by their real names: {{perf17}} is the standalone EJB client, the "forwarder" cluster is {{perf20}} and {{perf21}}, and the "target" cluster is {{perf18}} and {{perf19}}.
> The stack trace above is the first occurence of the exception, it appears on perf19 (https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-...). At that time, perf18 is just shutting down gracefully, but the perf19 log clearly shows that both Infinispan and JGroups have already figured out that perf18 went away. Still, the absence of graceful shutdown for transactions might be an explanation... except that there's no reason why the cache on perf19 would be in an invalid state if it's perf18 who is going down. So maybe perf19 had to reach out to perf18 for some reason and the exception actually comes from perf18... but the cache is REPL, so perf19 should have all data locally already and it shouldn't really have to reach out to perf18.
> So, not really sure why it happens.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6701) MBeanServer.isRegistered() fails when the security manager is enabled
by Derek Horton (JIRA)
Derek Horton created WFLY-6701:
----------------------------------
Summary: MBeanServer.isRegistered() fails when the security manager is enabled
Key: WFLY-6701
URL: https://issues.jboss.org/browse/WFLY-6701
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.Final
Reporter: Derek Horton
Assignee: Jason Greene
Calling MBeanServer.isRegistered() in a servlet fails with the following error when the security manager is enabled:
:WFSM000001: Permission check failed (permission "("org.jboss.as.controller.access.rbac.RunAsRolePermission" "org.jboss.as.controller.access.rbac.RunAsRolePermission.SUPERUSER")" in code source "(vfs:/content/SimpleWar.war/WEB-INF/classes <no signer certificates>)" of "null")
The code looks like the following:
final MBeanServer server = ManagementFactory.getPlatformMBeanServer();
final ObjectName mbeanName = new ObjectName("ima.test:type=imaTest");
System.out.println("*** calling MBeanServer.isRegistered() - "+server.isRegistered(mbeanName));
The META-INF/jboss-permissions.xml looks like the following:
<?xml version="1.0" encoding="UTF-8"?>
<permissions xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="7">
<permission>
<class-name>javax.management.MBeanServerPermission</class-name>
<name>createMBeanServer</name>
</permission>
<permission>
<class-name>org.jboss.as.controller.access.rbac.RunAsRolePermission</class-name>
<name>*</name>
</permission>
</permissions>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months