All version of GemFire which include Partitioned Regions, Continuous Query, and Eviction.
Presently, GemFire allows you to register a CQ (continuous query) on a partitioned region eviction configured with the local-destroy action. This generally works but may cause inconsistency when sending CQ events between members in the partitioned region. This article provides a detailed explanation of the cause of this issue.
Symptoms and Cause
Due to the particulars of eviction in GemFire, when eviction is configured with the local-destroy action each member hosting the partitioned region performs the local-destroy independently and without synchronization. As a result, CQ clients may receive varying events depending on which member those clients are connected to.
As an example, consider the following example:
- There are two members, MemberA and MemberB. Each member has a partitioned region configured with eviction, with local-destroy, and one redundant copy.
- MemberA is the primary for a given entry while MemberB is its secondary.
- There are two CQ clients, ClientA and ClientB. ClientA connects to MemberA while ClientB connects to MemberB.
- According to eviction setting, the entry on secondary is evicted and destroyed locally first. However, this particular data entry is destroyed by a destroy region operation before eviction is triggered on the primary at MemberA. (This could happen due to differences between each members memory usage, workload, configuration, etc.)
In situation, a CQ event is sent to ClientA because the entry still existed on the primary when the destroy region operation was invoked. On the other hand, the CQ event is not sent to ClientB because the entry had already been evicted on the secondary, MemberB.
At present, the only way to assure that CQ events cannot be missed in any situation, you should not configure partitioned on which you will be running CQs with the local-destroy eviction action.