This should all be resolved with my commits that reverted serialization
changes for classes implementing DataSerializableFixedID.
We were trying to protect Geode internals from being PDX serialized as
in GEODE-4822, where a Spring PDXSerializer was introduced into a server
that PDX-serialized java.util collection classes and caused grave
problems when pdx-read-serialized was set to true.
On 4/5/18 11:47 AM, Kirk Lund wrote:
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.
