[
https://issues.apache.org/jira/browse/GEODE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17268887#comment-17268887
]
ASF GitHub Bot commented on GEODE-8671:
---------------------------------------
DonalEvans commented on a change in pull request #5925:
URL: https://github.com/apache/geode/pull/5925#discussion_r561329417
##########
File path:
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/RegionConcurrentOperationDUnitTest.java
##########
@@ -131,6 +140,49 @@ public void
getOnPreLoadedRegionFromMultipleThreadsReturnSameObject() throws Exc
assertThat(cacheRule.getCache().getRegion(regionName).size()).isEqualTo(1);
}
+ @Test
+ public void
getOnPartitionedRegionFromMultipleThreadsReturnsDifferentPdxInstances()
+ throws Exception {
+ String regionName = getClass().getSimpleName();
+ CacheFactory cacheFactory = new CacheFactory();
+ cacheFactory.setPdxReadSerialized(true);
+ cacheRule.createCache(cacheFactory);
+ InternalCache cache = cacheRule.getCache();
+ cache.setCopyOnRead(true);
+ Region region = cache.createRegionFactory(PARTITION)
Review comment:
The compiler warning here (and elsewhere in the file) can be avoided by
using `Region<Object, Object>`.
##########
File path:
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/RegionConcurrentOperationDUnitTest.java
##########
@@ -131,6 +140,49 @@ public void
getOnPreLoadedRegionFromMultipleThreadsReturnSameObject() throws Exc
assertThat(cacheRule.getCache().getRegion(regionName).size()).isEqualTo(1);
}
+ @Test
+ public void
getOnPartitionedRegionFromMultipleThreadsReturnsDifferentPdxInstances()
+ throws Exception {
+ String regionName = getClass().getSimpleName();
+ CacheFactory cacheFactory = new CacheFactory();
+ cacheFactory.setPdxReadSerialized(true);
+ cacheRule.createCache(cacheFactory);
+ InternalCache cache = cacheRule.getCache();
+ cache.setCopyOnRead(true);
+ Region region = cache.createRegionFactory(PARTITION)
+ .create(regionName);
+
+ // Keep doing this concurrency test for 30 seconds.
+ long endTime = Duration.ofSeconds(30).toMillis() +
System.currentTimeMillis();
+
+ while (System.currentTimeMillis() < endTime) {
+ Callable<Object> getValue = () -> {
+ while (true) {
+ Object value = region.get(key);
+ if (value != null) {
+ return value;
+ }
+ }
+ };
+
+ // In this test, two threads are doing gets. One thread puts the value
+ // We expect that the threads will *always* get different PdxInstance
values
+ Future get1 = executorServiceRule.submit(getValue);
+ Future get2 = executorServiceRule.submit(getValue);
+ Future put = executorServiceRule.submit(() -> region.put(key, new
TestValue()));
Review comment:
Compiler warnings here (and elsewhere in the file) can be avoided by
using `Future<Object>`.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Two threads calling get and retrieve the same PdxInstance, resulting in
> corruption
> ----------------------------------------------------------------------------------
>
> Key: GEODE-8671
> URL: https://issues.apache.org/jira/browse/GEODE-8671
> Project: Geode
> Issue Type: Improvement
> Components: regions
> Reporter: Dan Smith
> Assignee: Jianxia Chen
> Priority: Major
> Labels: GeodeOperationAPI, blocks-1.14.0, caching-applications
>
> Even if copy-on-read is set to true, two threads calling get on a partitioned
> region can end up with the same PdxInstance object.
> This is problematic because some PdxInstances methods are not thread safe.
> Although the underlying bytes are immutatable, the PDXInstance has a
> ByteSource with a position field that changes. That means two threads doing
> serialization or calling toString on the PdxInstance could result in one or
> more threads getting a corrupt read.
> It looks like they are ending up with the same instance because of the
> behavior in LocalRegion.optimizedGetObject. We use futures to make sure there
> is only 1 get that goes through, and both threads receive the same value.
>
> Ending up in optimizedGetObject requires a race with the put, because if the
> value was in the cache at the beginning of the get it would be returned
> earlier in the get process.
> I put a test that reproduces this issue here -
> https://github.com/upthewaterspout/geode/pull/new/feature/pdx-instances-shared
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
