Re: Gemfire proxy cache race condition bug?

[Akihiro Kitada <ak...@pivotal.io>]

Hello David,

Have you set conserve-sockets=false to avoid potential connection level
dead-lock? And also, please refer to the following KB to avoid any types of
dead-locks.

https://discuss.pivotal.io/hc/en-us/articles/201298393

Thanks.



-- 
Akihiro Kitada  |  Staff Customer Engineer |  +81 80 3716 3736
Support.Pivotal.io <http://support.pivotal.io/>  |  Mon-Fri  9:00am to
5:30pm JST  |  1-877-477-2269
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>


2017-03-04 21:58 GMT+09:00 David Wales <da...@gmail.com>:

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