Mailing-List: contact dev-help@geode.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geode.apache.org
MIME-Version: 1.0
In-Reply-To: <CANgOuWsCQjo+0wsa=QYQ52DwM_Xp6rdTQP6xjvNG+iEL+3_PRw@mail.gmail.com>
References: <CANsw5GOXTRWFPSRY56erxAretFYb+4L-un=_aWAKJyEX6jRT-g@mail.gmail.com>
 <CANgOuWsCQjo+0wsa=QYQ52DwM_Xp6rdTQP6xjvNG+iEL+3_PRw@mail.gmail.com>
From: Darrel Schneider <dschneider@pivotal.io>
Date: Mon, 6 Mar 2017 11:51:07 -0800
Message-ID: <CAJCfvb6fXkJR37pq_Zs4gZ+1MzUJ9KsoOwf0aGU2h-Mh-rq-vQ@mail.gmail.com>
Subject: Re: Gemfire proxy cache race condition bug?
To: user@geode.apache.org
Cc: dev@geode.apache.org, user@geode.incubator.apache.org,
	geode <dev@geode.incubator.apache.org>
Content-Type: multipart/alternative; boundary=001a114032aa63026a054a15372f
archived-at: Mon, 06 Mar 2017 19:56:45 -0000

--001a114032aa63026a054a15372f
Content-Type: text/plain; charset=UTF-8

This is a known limitation of CacheListeners on a PROXY region. On other
types of regions the local region entry that the operation is modifying is
synchronized during the operation and during the CacheListener invocation.
That is what the javadocs on the CacheListener calls "holding a lock on the
entry." But since a PROXY region has none of its own state it has no local
region entry to hold a lock on. The javadocs should be changed to mention
this. Did you see this in some other place in the docs?

Another thing to keep in mind is that even when the entry is locked during
CacheListener invocation this does not guarantee a total ordering across
the distributed system. In particular the events you receive on a client
are async with those that occur on the server. You best bet is to use a
CacheListener on the server side on a partitioned region. All the modify
ops go through the single primary.

Another odd thing about a PROXY is that "get" will call afterCreate on a
listener on the proxy even when the get was a hit on the server. This is
because our PROXY logic always looks at the local state (not the server
state) when deciding on what CacheListener method to call. Ideally you
would only have "get" deliver afterCreate when the "get" does a load.

On Mon, Mar 6, 2017 at 8:55 AM, Michael Stolz <mstolz@pivotal.io> wrote:

> If you always do whatever processing you are planning to do inside the
> CacheListener and use the "newValue" field that is supplied to that
> callback you will always begin processing in the order the data was
> received. I suppose if you want to ensure that you are completing
> processing in the correct order you would need to synchronize on your
> callback as you said.
>
> To "prime the pump" you can use get as you are now, or registerInterest
> with a list of keys or wildcard on string-based keys. Register interest can
> optionally deliver the initial value followed by all updates in the correct
> order.
>
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771 <(631)%20835-4771>
>
> On Sat, Mar 4, 2017 at 7:58 AM, David Wales <davidmichaelwales@gmail.com>
> wrote:
>
>> Hi there,
>>
>> I have a client proxy cache with an associated cache listener. An
>> invocation of the region get method will trigger the afterCreate callback.
>> I realized this call back was on the same thread that called get and is
>> different to the thread that dispatches the region updates. So I had a
>> look
>> at the code and there seems to be no synchronization. I could mark the
>> cache listener methods as synchronized but this doesn't fully mitigate the
>> race. How does one get the initial state of an entry in a region in a way
>> that synchronizes with updates on. Is this a known limitation or a bug as
>> the documentation talks about cache listener methods being mutually
>> exclusive?
>>
>> Much appreciated
>> Thank you
>> David
>>
>
>

--001a114032aa63026a054a15372f--