I disabled PartitionedRegionQueryDUnitTest last week because it hung.
Over the last week, I overhauled this test and extracted several test
methods that were very unique to their own test classes. Precheckin was
green, but our two checkins collided. Looks like one of these extracted
tests hung. What needs to change?
commit 6b2d45ac34663b1eeda6c2e921b73d1a114b2a9a (origin/develop, develop)
Author: Kirk Lund <kl...@apache.org>
Date: Wed Apr 4 10:29:37 2018 -0700
GEODE-4970: Overhaul and split up PartitionedRegionQueryDUnitTest
(#1718)
Rename:
* PartitionedRegionQueryDUnitTest -> PRQueryDistributedTest
Extract the following tests from PRQueryDistributedTest:
* PRQueryWithIndexAndPdxDistributedTest
* PRQueryWithIndexDistributedTest
* PRQueryWithOrderByDistributedTest
* PRQueryWithPdxDuringRebalanceRegressionTest
* PRWithIndexAfterRebalanceRegressionTest
Introduce and use:
* InternalClientCache interface
* ClientCacheRule
On Thu, Apr 5, 2018 at 9:00 AM, Bruce Schuchardt <bschucha...@pivotal.io>
wrote:
> The distributedTest hangs are once again caused by deserialization
> problems in a query message class. The deserialization errors are caused
> by the fix for GEODE-4822 <https://issues.apache.org/jir
> a/browse/GEODE-4822>, which I am going to revert this morning. We
> obviously don't have the test coverage to ensure that this fix doesn't
> cause problems and I don't want to keep finding new and unusual hangs.
>
> Details, if you have the time:
>
> The hang occurred because someone checked in a new
> query/indexing/pdx-read-serialized test at the same time I checked in a
> fix for a different hang. The message class that I modified turns out to
> have a field that sometimes holds an internal Geode object and other times
> holds a user object. In the former case we want to protect against it
> having been PDX serialized by ignoring pdx-read-serialized. In the latter
> case we want to respect the user's pdx-read-serialized setting. There's no
> straightforward way of knowing which kind of object it is, internal or
> external, before deserializing it.
>
>
