geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (GEODE-4285) Temporary failure with "Unable to determine PDXType" using WAN
Date Thu, 11 Jan 2018 23:55:00 GMT


ASF GitHub Bot commented on GEODE-4285:

upthewaterspout opened a new pull request #1273: 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.
   Thank you for submitting a contribution to Apache Geode.
   In order to streamline the review of the contribution we ask you
   to ensure the following steps have been taken:
   ### For all changes:
   - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
   - [ ] Has your PR been rebased against the latest commit within the target branch (typically
   - [ ] Is your initial contribution a single, squashed commit?
   - [ ] Does `gradlew build` run cleanly?
   - [ ] Have you written or updated unit tests to verify your changes?
   - [ ] If adding new dependencies to the code, are these dependencies licensed in a way
that is compatible for inclusion under [ASF 2.0](
   ### Note:
   Please ensure that once the PR is submitted, you check travis-ci for build issues and
   submit an update to your PR as soon as possible. If you need help, please send an
   email to

This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

> Temporary failure with "Unable to determine PDXType" using WAN
> --------------------------------------------------------------
>                 Key: GEODE-4285
>                 URL:
>             Project: Geode
>          Issue Type: Bug
>          Components: serialization
>            Reporter: Dan Smith
> We tracked down a race condition in distributing PDX types to the remote side of a WAN
> 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

View raw message