如何解决Wildfly中的“15秒后无法获取锁定”的错误

14

我的Web应用程序是<distributable/>的,但也部署到本地开发工作中独立的Wildfly实例。有时我们会调用后端,可能会停顿几秒钟,这经常导致像下面显示的异常。

鉴于我对长时间运行的后端请求没有控制权,我该如何解决这个问题?

14:55:04,808 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-6) ISPN000136: Error executing command LockControlCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key LA6Q5r9L1q-VF2tyKE9Pc_bO9yYtzXu8dYt8l-BQ and requestor GlobalTransaction:<null>:37:local. Lock is held by GlobalTransaction:<null>:36: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.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.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:140)
    at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:726)
    at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:370)
    at au.com.agic.settings.listener.SessionInvalidatorListener.clearSession(SessionInvalidatorListener.java:57)
    at au.com.agic.settings.listener.SessionInvalidatorListener.requestInitialized(SessionInvalidatorListener.java:52)
    at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:245)
    at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:283)
    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)
3个回答

11

我认为答案是更新infinispan配置如下,将锁定超时时间增加到60秒。

<cache-container name="web" default-cache="passivation"
    module="org.wildfly.clustering.web.infinispan">
    <local-cache name="passivation">
        <locking isolation="REPEATABLE_READ" striping="false" acquire-timeout="60000" />
        <transaction mode="BATCH" />
        <file-store passivation="true" purge="false" />
    </local-cache>
    <local-cache name="persistent">
        <locking isolation="REPEATABLE_READ" striping="false" acquire-timeout="60000" />
        <transaction mode="BATCH" />
        <file-store passivation="false" purge="false" />
    </local-cache>
</cache-container>

2
我发现在<transaction mode="batch" />元素上设置 locking="OPTIMISTIC" 也很有帮助。 - Stijn de Witt
@Phyxx,您能否帮忙解释一下为什么将超时时间设置为60秒可以解决问题?当超时时间达到60秒后会发生什么? - garykwwong
我认为增加超时时间是一个短期解决方案,最终会使问题变得更严重。 - thierryler
这可能也有所帮助 https://access.redhat.com/solutions/2776221 - Carlos Lacerda
由于:org.infinispan.util.concurrent.TimeoutException: ISPN000299: 在60秒内无法为键i369vnLfx8pZ9Oj5和请求者CommandInvocation获取锁定。 它连60秒都不起作用:( - Aguid

0

对于一个独立的程序,我遇到了同样的错误

我使用的是这个:

<cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
    <transport lock-timeout="60000"/>
    <distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">  <!-- IN 7.1+ REMOVE mode="..." IF PRESENT -->
        <locking isolation="REPEATABLE_READ"/>                               <!-- REMOVE THIS LINE -->
        <transaction mode="BATCH"/>                                          <!-- REMOVE THIS LINE -->
        <file-store/>
    </distributed-cache>
</cache-container>

但是将其改为:

<cache-container name="web" default-cache="passivation" module="org.wildfly.clustering.web.infinispan">
  <local-cache name="passivation">
      <file-store passivation="true" purge="false"/>
  </local-cache>
  <local-cache name="persistent">
      <file-store passivation="false" purge="false"/>
  </local-cache>
</cache-container>

然后它就工作了。


0
在使用服务器端事件时遇到了相同的问题。 在研究问题时发现异步servlet存在/曾经存在的错误, SSE隐式地是异步的。
找到了解决该问题的RedHat bug的解决方案: https://access.redhat.com/solutions/2776221 这与yun_jay的解决方案是一样的,只是"官方"的。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接