You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "xiaojian zhou (JIRA)" <ji...@apache.org> on 2017/06/08 18:30:18 UTC

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

xiaojian zhou created GEODE-3055:
------------------------------------

             Summary: 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
             Fix For: 1.2.0


/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.3.15#6346)