[ 
https://issues.apache.org/jira/browse/GEODE-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16329697#comment-16329697
 ] 

ASF subversion and git services commented on GEODE-4285:
--------------------------------------------------------

Commit da426077cc621196907df59c6a9e5f7dce907333 in geode's branch 
refs/heads/develop from [~geodeintegration]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=da42607 ]

GEODE-4285: Get a distributed lock if we can't find a PDX type

If we are unable to find a PDX type during a get, will we get a
distributed lock and try again. This prevents races where the type may
be in the middle of distribution.

Adding a dunit test for the race condition that requires this fix.

> Temporary failure with "Unable to determine PDXType" using WAN
> --------------------------------------------------------------
>
>                 Key: GEODE-4285
>                 URL: https://issues.apache.org/jira/browse/GEODE-4285
>             Project: Geode
>          Issue Type: Bug
>          Components: serialization
>            Reporter: Dan Smith
>            Priority: Major
>              Labels: pull-request-available
>
> We tracked down a race condition in distributing PDX types to the remote side 
> of a WAN site.
> When using a parallel sender, all primaries on the sending side are 
> dispatching the same PDX type in parallel.
> On the receiving side, the first gateway batch will get a distributed lock in 
> PeerTypeRegistration.addRemoteType
> {code}
> if (!r.containsKey(typeId)) {
>         // This type could actually be for this distributed system,
>         // so we need to make sure the type is published while holding
>         // the distributed lock.
>         lock();
>         try {
>           r.putIfAbsent(typeId, type);
>         } finally {
>           unlock();
>         }
>       }
> {code}
> However, the second gateway batch that is received will continue on without 
> getting the distributed lock because r.containsKey() will return true.
> The second batch could have values that require this type. But without 
> getting the lock, those fails will get to members that need the type 
> potentially before the first batch is finished distributing the type.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to