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

ASF GitHub Bot commented on GEODE-8672:
---------------------------------------

kohlmu-pivotal commented on a change in pull request #5691:
URL: https://github.com/apache/geode/pull/5691#discussion_r516206148



##########
File path: 
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/control/RebalanceOperationDistributedTest.java
##########
@@ -2820,68 +2823,58 @@ private void doRebalance() throws TimeoutException, 
InterruptedException {
 
   private void doConcurrentPutInTx(String s) throws Exception {
     for (int i = 0; i < totalNumberOfBuckets; i++) {
-      synchronized (list) {
-        list.add(i);
-      }
-    }
-
-    Thread[] threads = new Thread[totalNumberOfBuckets];
-    for (int i = 0; i < totalNumberOfBuckets; i++) {
-      threads[i] = new Thread(() -> doPutOpInTx(s));
+      queue.add(i);
     }
 
+    ExecutorService pool = Executors.newCachedThreadPool();
+    Future<?>[] futures = new Future<?>[totalNumberOfBuckets];
     for (int i = 0; i < totalNumberOfBuckets; i++) {
-      threads[i].start();
+      futures[i] = pool.submit(() -> doPutOpInTx(s));

Review comment:
       I was more thinking in the line of using the `invokeAll` rather than the 
single `submit`. With `invokeAll` you can create all the operations up front 
and then invoke all of them at the same time.
   
   Are we not concerned that if we do it this way, that there is a possibility 
that the concurrency issue is possibly not ever hit?




----------------------------------------------------------------
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


> Concurrent transactional destroy with GII could cause an entry to be removed 
> and version information to be lost
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-8672
>                 URL: https://issues.apache.org/jira/browse/GEODE-8672
>             Project: Geode
>          Issue Type: Bug
>          Components: regions
>    Affects Versions: 1.1.0
>            Reporter: Eric Shu
>            Assignee: Eric Shu
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.14.0
>
>
> In a newly rebalanced bucket, while GII is in progress, a transactional 
> destroy is applied to cache. There is a logic that it should be in token mode 
> and leaves the entry as a Destroyed token, even though the version tag of the 
> entry indicates that it has the correct version.
> However, at end of the GII, there is a 
> cleanUpDestroyedTokensAndMarkGIIComplete method removes all the destroyed 
> entries – this wipes off the entry version tag information and cause the 
> subsequent creates starts fresh with new version tags.
> This could leads to client server data inconsistency as the newly created 
> entries will be ignored by the clients as the newly created entry has lower 
> version number while client has high ones.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to