通过高速缓存进行迭代期间的Infinispan-8阻止状态

问题描述

我正在使用infinispan 8.2.11。在使用cache.entrySet（）。iterator（）进行高速缓存迭代期间，线程被卡住并且不移动。这是我收集的线程转储：

"EJB default - 32" #586 prio=5 os_prio=0 tid=0x000055ce2f619000 nid=0x2853 runnable [0x00007f8780c7a000]
   java.lang.Thread.State: TIMED_WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000006efb93ba8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163)
        at org.infinispan.stream.impl.distributedCacheStream$Iteratorsupplier.get(distributedCacheStream.java:754)
        at org.infinispan.util.CloseableSuppliedIterator.getNext(CloseableSuppliedIterator.java:26)
        at org.infinispan.util.CloseableSuppliedIterator.hasNext(CloseableSuppliedIterator.java:32)
        at org.infinispan.stream.impl.RemovableIterator.getNextFromIterator(RemovableIterator.java:34)
        at org.infinispan.stream.impl.RemovableIterator.hasNext(RemovableIterator.java:43)
        at org.infinispan.commons.util.Closeables$IteratorAsCloseableIterator.hasNext(Closeables.java:93)
        at org.infinispan.stream.impl.RemovableIterator.getNextFromIterator(RemovableIterator.java:34)
        at org.infinispan.stream.impl.RemovableIterator.hasNext(RemovableIterator.java:43)
        at org.infinispan.commons.util.IteratorMapper.hasNext(IteratorMapper.java:26)

我在Jboss社区档案中找到了一篇描述类似问题的文章：https://developer.jboss.org/thread/271158。我相信infinispan 9中提供了一个修复程序，可以解决此问题：ISPN-9080

是否可以将此修复程序反向移植到infinispan-8中？不幸的是，我无法在项目中提升infinispan的版本。

解决方法

很遗憾，我们不维护此类较旧的版本。建议的方法是更新到最新版本。如果那不可能，您可以尝试修补较旧的版本，因为您有可用的更改https://github.com/infinispan/infinispan/pull/5924/files

还要注意，这不能解决实际问题。这只是解决了实际问题的症状。实际问题是由于某种原因未安装最新的拓扑，但是原始发布者无法提供足够的信息来确定原因。

,

无论如何，我建议考虑考虑更新Infinispan版本。 您可能会错过许多修复程序，因为版本11是当前稳定的版本，会遇到已经修复的问题。

但是，您遇到的问题是集群中发生了某些事情，并且集群拓扑更新丢失了。 如果群集稳定，则不会发生此问题。 因此，如果您能够找到导致“不稳定”群集的原因，则可以有意地停止/启动节点，并且可以接受。