Fatal编程技术网
  • ignite/
  • 当调用另一个缓存中的缓存移除时，Ignite服务挂起'；“调用处理器”；条纹池中可能出现饥饿现象；？

当调用另一个缓存中的缓存移除时，Ignite服务挂起'；“调用处理器”；条纹池中可能出现饥饿现象；？

ignite

当调用另一个缓存中的缓存移除时，Ignite服务挂起'；“调用处理器”；条纹池中可能出现饥饿现象；？,ignite,Ignite,点燃原木有饥饿警告并停止提供服务： [12:55:22,080][WARNING][grid-timeout-worker-#71][G] >>> Possible starvation in striped pool. Thread name: sys-stripe-25-#26 Deadlock: false Completed: 16272032 Thread [name="sys-stripe-25-#26", id=51, state=WAIT

点燃原木有饥饿警告并停止提供服务：

[12:55:22,080][WARNING][grid-timeout-worker-#71][G] >>> Possible starvation in striped pool.
    Thread name: sys-stripe-25-#26
    Deadlock: false
    Completed: 16272032
Thread [name="sys-stripe-25-#26", id=51, state=WAITING, blockCnt=79, waitCnt=15616666]
    at sun.misc.Unsafe.park(Native Method)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
    at o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
    at o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
    at o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.remove0(GridDhtAtomicCache.java:716)
    at o.a.i.i.processors.cache.GridCacheAdapter.remove(GridCacheAdapter.java:3084)
    at o.a.i.i.processors.cache.GridCacheAdapter.remove(GridCacheAdapter.java:3065)
    at o.a.i.i.processors.cache.IgniteCacheProxyImpl.remove(IgniteCacheProxyImpl.java:1131)
    at o.a.i.i.processors.cache.GatewayProtectedCacheProxy.remove(GatewayProtectedCacheProxy.java:998)
    at com.test.info.TestInfoBasicExecutor.handleCurrentLevel(TestInfoBasicExecutor.java:281)
    at com.test.info.TestInfoBasicExecutor$infoEntryProcessor.process(TestInfoBasicExecutor.java:514)
    at com.test.info.TestInfoBasicExecutor$infoEntryProcessor.process(TestInfoBasicExecutor.java:453)
    at o.a.i.i.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.runEntryProcessor(GridCacheMapEntry.java:5142)
    at o.a.i.i.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4550)
    at o.a.i.i.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4367)
    at o.a.i.i.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3051)
    at o.a.i.i.processors.cache.persistence.tree.BPlusTree$Invoke.access$6200(BPlusTree.java:2945)
    at o.a.i.i.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1717)
    at o.a.i.i.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1600)
    at o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1199)
    at o.a.i.i.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1357)
    at o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:345)
    at o.a.i.i.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1767)
    at o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2420)
    at o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1883)
    at o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1736)
    at o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628)
    at o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3055)
    at o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:130)
    at o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:266)
    at o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:261)
    at o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
    at o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
    at o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
    at o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
    at o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
    at o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
    at o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
    at o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
    at o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
    at o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
    at o.a.i.i.util.StripedExecutor$Stripe.run(StripedExecutor.java:505)
    at java.lang.Thread.run(Thread.java:745)
我使用invoke更新缓存A，在缓存A的etnryprocessor中， 我知道处理器已经被锁调用了，我只是在为另一个缓存库更新这个条目， 我已经检查了缓存A的值，并根据该值在测试中更新缓存B条目，即放置或删除， put正常，但对于remove，似乎remove cause服务挂起：

    at com.test.info.TestInfoBasicExecutor.handleCurrentLevel(TestInfoBasicExecutor.java:281)
    at com.test.info.TestInfoBasicExecutor$infoEntryProcessor.process(TestInfoBasicExecutor.java:514)
    at com.test.info.TestInfoBasicExecutor$infoEntryProcessor.process(TestInfoBasicExecutor.java:453)
====================================================== 更新0702:

为了防止饥饿，我更改了代码：

在点火服务A的执行功能中：

cacheA.invoke（记录）{ //做记录的过程

igniteQueue.put（已处理的_记录）

}

在点火服务B的执行功能中：

保存的_处理的_记录=igniteQueue.take（）

=================

我试着用这种方法来防止饥饿，它运行平稳时 旧代码有饥饿（TPS很低），但当我运行高TPS时， “条纹池中可能的饥饿”又回来了

似乎我在cache.invoke中使用了igniteQueue，这与cache.invoke中以前的缓存相比也是不正确的

当我想对缓存中的每条记录进行处理，然后根据处理后的记录更新其他缓存时，似乎不可能？用于处理Ignite消息的条带化池。看起来由于某种原因，此池中的所有线程都在等待某个操作（从日志中的缓存中删除）。这可能与网络问题有关，或者删除需要花费大量时间（例如，您要删除所有数据）

请附加线程转储和测试代码以进行调查，好吗？

用于处理Ignite消息的条带化池。看起来由于某种原因，此池中的所有线程都在等待某个操作（从日志中的缓存中删除）。这可能与网络问题有关，或者删除需要花费大量时间（例如，您要删除所有数据）

请附加线程转储和测试代码以进行调查，好吗？

您应该避免在条目处理器中执行缓存操作，即使这些操作属于其他缓存。原因是所有这些操作将使用相同的线程池-这可能会导致饥饿。

您应该避免在条目处理器中执行缓存操作，即使这些操作属于其他缓存。原因是所有这些操作都将使用相同的线程池-这可能会导致饥饿。

我有3个线程池和5个客户端，客户端从客户端获取缓存信息，我不知道这个问题是否与太多客户端有关，无法检索同一缓存，对于回溯，服务器无法转储，如果出现错误，因此，我只是转储客户端的线程回溯，并将其粘贴到这里：我有3个客户端和5个客户端，客户端从客户端获取缓存信息，我不知道这个问题是否与太多客户端相关，无法检索同一缓存，对于回溯，服务器无法转储它，因此我只是转储客户端的线程回溯，然后粘贴到这里：谢谢你的回答，有没有关于如何进行这种更新的建议a缓存的条目，在另一个缓存的条目上，我尝试在我的帖子中将更新更改为缓存B，以将条目记录到另一个ignite队列，并启动一个服务使用take（）检查队列方法并以此为基础来更新ignite缓存B，目前它还可以工作，但我想知道这种方法是否可以避免线程饥饿？您能否澄清这里“依赖”的含义？你想要什么样的一致性/原子性保证？很抱歉反应太晚，我已经更新了我的帖子以使我的问题更清楚，请检查原始帖子中的更新--0702更新，谢谢。
IgniteQueue
使用引擎盖下的Ignite缓存，因此，条带化池中的
可能饥饿的原因是相同的。谢谢你的回答，是否有任何关于如何进行这种更新的建议a缓存的条目将被删除，并且在另一个缓存的条目上，我已尝试在我的帖子中将更新更改为缓存B，以将条目记录到另一个ignite队列中，然后启动一个服务，用take（）方法检查队列，并以此为基础更新ignite缓存B，现在它可以工作了，但我想知道这种方法是否可以避免线程饥饿？你能澄清一下这里的“依赖”是什么意思吗？你想要什么样的一致性/原子性保证？很抱歉反应太晚，我已经更新了我的帖子，以使我的问题更清楚，请检查原始帖子中的更新--0702更新，谢谢。
IgniteQueue
在引擎盖下使用Ignite缓存，因此条带池中
可能饥饿的原因是相同的。