Causing Inconsistency with CQ Event's Operation if Registering CQ on Partitioned Region with Eviction Setting of Local-destroy
search cancel

Causing Inconsistency with CQ Event's Operation if Registering CQ on Partitioned Region with Eviction Setting of Local-destroy

book

Article ID: 294149

calendar_today

Updated On:

Products

VMware Tanzu Gemfire

Issue/Introduction

Presently, GemFire allows you to register a continuous query (CQ) 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 and explains how to resolve the issue.

Environment


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 this 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.

Resolution

At present, the only way to assure that CQ events are not missed in any situation is, you should not configure partitioned on which you will be running CQs with the local-destroy eviction action.

Additional Information

Environment

All versions of the GemFire which include Partitioned Regions, Continuous Query, and Eviction.