[jira] [Closed] (GEODE-707) Concurrent cache-load doesn't invoke loader multiple times if there is an exception in the first load

["Anthony Baker (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anthony Baker closed GEODE-707.
-------------------------------

> Concurrent cache-load doesn't invoke loader multiple times if there is an exception in the first load
> -----------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-707
>                 URL: https://issues.apache.org/jira/browse/GEODE-707
>             Project: Geode
>          Issue Type: Bug
>          Components: core
>            Reporter: Bruce Schuchardt
>            Assignee: Bruce Schuchardt
>             Fix For: 1.0.0-incubating.M1
>
>
> This is from an old Pivotal ticket that was fixed in bugfix branches but never made it to develop.  The ticket text follows:
> I see following behavior when we have a condition where 2 get() calls are sent concurrently for the same key in which Loader is called,
>     If the first call is sent to Loader we create a Future.
>     For second call we wait on this Future.
>     Before first call is finished we check second call its a cache miss here as well(which we have checked before) we have isCreate=true.
>     In case when isCreate is true in that flow we actually return null if we can't see the value(which can be true in case we got an exception on the first Loader call). 
> Now from customer point of view this is inconsistent, as they except GemFire? to try again with the Loader and return exception as that is the true state here.
> [Darrel's reply]
> The first get creates a future and when it completes sets the future. If the first get fails with an exception (like a CacheLoaderException?) it still sets the future with this code in a finally block:
>     VersionTag? tag = (clientEvent==null)? null : clientEvent.getVersionTag();
>     thisFuture.set(new Object[]{result, tag});
> In the case of the first get failing with an exception "result" will be null so it sets the future to an array whose first element is null.
> The second get is waiting on the future. It returns this array and sees the first element as null which causes it to just return null. I think what it used to do was see Future.get return null (instead of an array with null in it) and this caused it to fall through and attempt to do the load itself which I think is what the customer also expects. You can see in the code this was what was intended by this comment that still remains:
>     if value == null, try our own search/load
> Also if you look at the code in PartitionedRegion? that overrides this LocalRegion? code you will see that it does exactly this; if an exception is thrown the future is set to null and the second get see null returned from the future, falls through, and attempts the load itself.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)