[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 commented on WFLY-6696:
-----------------------------------
It's impossible use the wildfly in cluster, because this bug. It's works when I remove the <distributable/> in the web.xml.
> 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)
10 years
[JBoss JIRA] (REMJMX-108) Switch to Remoting 5
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-108?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on REMJMX-108:
-----------------------------------------
I would suggest if we can we make that a follow up task,if there is any change to the message format we will need a new message version anyway, switching to Elytron authentication is the first important step. But good to know we have an InvocationTracker available now - that felt like a problem every client library was having to solve.
> Switch to Remoting 5
> --------------------
>
> Key: REMJMX-108
> URL: https://issues.jboss.org/browse/REMJMX-108
> Project: Remoting JMX
> Issue Type: Task
> Components: Build
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha1
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (REMJMX-108) Switch to Remoting 5
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-108?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on REMJMX-108:
-----------------------------------------
Hopefully that will solve another problem we had integrating Remoting JMX with the CLI - where we have to manually make the connection available if we want to share it.
Also once we get back within the application server it could hopefully make proxying the MBeanServer from a different process much much easier.
> Switch to Remoting 5
> --------------------
>
> Key: REMJMX-108
> URL: https://issues.jboss.org/browse/REMJMX-108
> Project: Remoting JMX
> Issue Type: Task
> Components: Build
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha1
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (REMJMX-108) Switch to Remoting 5
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/REMJMX-108?page=com.atlassian.jira.plugin... ]
David Lloyd commented on REMJMX-108:
------------------------------------
This will have to be done in lock-step with REMJMX-109. Also, this entails switching to Remoting client connection management - in other words, switching to {{Endpoint.getConnection()}} instead of {{Endpoint.connect()}}, and relying on {{Endpoint.getCurrent()}} instead of constructing custom endpoints for client or server. Locally configured authentication items should be considered "legacy" and could be used to construct a composite AuthenticationContext based on the captured one, if they are present, to allow them to continue to work.
> Switch to Remoting 5
> --------------------
>
> Key: REMJMX-108
> URL: https://issues.jboss.org/browse/REMJMX-108
> Project: Remoting JMX
> Issue Type: Task
> Components: Build
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha1
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years