[jira] [Commented] (GEODE-3055) waitUntilFlush did not check the brq's tempQueue, which caused data mismatch

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

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

ASF subversion and git services commented on GEODE-3055:
--------------------------------------------------------

Commit 40fb5fdf9e7053de7b1f1df0fc1adfd3fe78546b in geode's branch refs/heads/feature/GEM-1483 from zhouxh
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=40fb5fd ]

GEODE-3055: The old primary's the shadow bucket is not
initialized when rebalance remove it. Thus the new primary candidate can
never initialize from it. The fix is to wait until new primary exists before
remove the old primary's bucket in rebalance.


> waitUntilFlush did not check the brq's tempQueue, which caused data mismatch
> ----------------------------------------------------------------------------
>
>                 Key: GEODE-3055
>                 URL: https://issues.apache.org/jira/browse/GEODE-3055
>             Project: Geode
>          Issue Type: Bug
>            Reporter: xiaojian zhou
>            Assignee: xiaojian zhou
>              Labels: lucene
>
> /export/buglogs_bvt/xzhou/lucene/concParRegHAPersist-0601-171739
> lucene/concParRegHAPersist.conf
> A=accessor
> B=dataStore
> accessorHosts=1
> accessorThreadsPerVM=5
> accessorVMsPerHost=1
> dataStoreHosts=6
> dataStoreThreadsPerVM=5
> dataStoreVMsPerHost=1
> numVMsToStop=2
> redundantCopies=0
> no local.conf
> In dataStoregemfire5_7483/system.log, thread tid=0xdf, putAll Object_11066
> 17:22:27.135 tid=0xdf] generated tag {v1; rv13 shadowKey=2939
> 17:22:27.136 _partitionedRegionPARALLELGATEWAYSENDER_QUEUE_1 bucket : null // brq is not ready yet
> is enqueued to the tempQueue
> 17:22:27.272 tid=0xdf] generated tag {v3; rv15 shadowKey=3278
> 17:22:33.111 Subregion created: /_PR/_BAsyncEventQueueindex#partitionedRegionPARALLELGATEWAYSENDER_QUEUE_1
> vm_3_dataStore3_r02-s28_28143.log:
> 17:22:33.120 Put successfully in the queue shadowKey= 2939
> 17:22:33.156 tid=0x7fe started query
> 17:22:33.176 Peeked shadowKey= 2939
> So the root cause is: the event is still in tempQueue before it's processed, the query happened. WaitUntilFlush should wait until tempQueue is also flushed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)