死锁检测- Gemfire 8

Question

我用RegionShortcut.PARTITION和setRedundantCopies(1)定义了一个GemFire区域。在3个不同虚拟机上运行的3个应用程序正在使用这些区域。

当我关闭应用程序的VM时，我似乎有一个死锁，该应用程序刚刚向缓存中插入了一个项目(该项目的“所有者”)：

*被阻塞的进程:在region.put之前被阻塞。

*阻止进程:在尝试从区域中删除旧条目后，似乎被阻止。我怀疑这个操作是由CacheListenerAdapter提供的销毁机制调用的。

我在以下链接中读到了一些关于这个问题的文档：CacheListener Interface API和这个blog，它主要发现侦听器的使用是罪魁祸首。

但是，这个问题似乎已经在GemFire 6.x版本的for example: [here](https://www.vmware.com/support/vfabric-gemfire/doc/BugsFixedGemFire662.html) and [here] 中得到了解决和修复

因此，我想问：

1) Gemfire 8是否报告了此问题？还是7岁？

2)此问题的建议解决方法是什么？here中提到了3种不同的解决方法。还有其他的吗？有更好的选择吗？

仅供参考，阻塞进程的线程转储如下：

Owner stack trace: java.lang.Throwable
    at sun.misc.Unsafe.park(Native Method)
    at java.util.concurrent.locks.LockSupport.park(Unknown Source)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown Source)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(Unknown Source)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(Unknown Source)
    at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lockInterruptibly(Unknown Source)
    at com.gemstone.gemfire.internal.cache.BucketRegion.lockPrimaryStateReadLock(BucketRegion.java:780)
    at com.gemstone.gemfire.internal.cache.BucketRegion.doLockForPrimary(BucketRegion.java:719)
    at com.gemstone.gemfire.internal.cache.BucketRegion.beginLocalWrite(BucketRegion.java:704)
    at com.gemstone.gemfire.internal.cache.BucketRegion.basicDestroy(BucketRegion.java:1105)
    at com.gemstone.gemfire.internal.cache.PartitionedRegionDataStore.destroyLocally(PartitionedRegionDataStore.java:1511)
    at com.gemstone.gemfire.internal.cache.PartitionedRegion.destroyInBucket(PartitionedRegion.java:5440)
    at com.gemstone.gemfire.internal.cache.PartitionedRegionDataView.destroyExistingEntry(PartitionedRegionDataView.java:45)
    at com.gemstone.gemfire.internal.cache.PartitionedRegion.basicDestroy(PartitionedRegion.java:5317)
    at com.gemstone.gemfire.internal.cache.LocalRegion.validatedDestroy(LocalRegion.java:1330)
    at com.gemstone.gemfire.internal.cache.LocalRegion.destroy(LocalRegion.java:1317)
    at com.gemstone.gemfire.internal.cache.AbstractRegion.destroy(AbstractRegion.java:282)
    at com.gemstone.gemfire.internal.cache.LocalRegion.remove(LocalRegion.java:9513)

Answer 1

涉及CacheListeners的死锁是可能的。在最新的(GemFire 8.1) javadoc中记录了这种行为。以下是CacheListener文档中的相关摘录：

避免死锁的风险

CacheListener上的方法是在锁定EntryEvent所描述的条目时调用的，因此，如果侦听器方法需要很长时间才能执行，则会导致导致调用它的操作花费很长时间。此外，调用区域方法的侦听器代码可能会导致死锁。例如，在用于输入键k1的afterUpdate(EntryEvent)中，put( k2，someVal)被调用的同时，对于输入键afterUpdate(EntryEvent)，对于输入键k2调用put(k1，someVal)可能导致死锁。该共键依赖关系示例可以扩展为同区域依赖关系，其中区域A中的侦听器代码对B执行区域操作，而区域B中的侦听器代码对A执行区域操作。死锁可以是java级别的死锁，也可以是分布式多VM死锁，这取决于区域配置。为确保不会出现死锁，侦听器代码应使其他线程访问该区域，而不能等待该线程完成任务。