[
https://issues.apache.org/jira/browse/SOLR-11447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16205625#comment-16205625
]
ASF subversion and git services commented on SOLR-11447:
--------------------------------------------------------
Commit dea85256a485800b8ddebc149bc6765e7da90412 in lucene-solr's branch
refs/heads/branch_7x from [~caomanhdat]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=dea8525 ]
SOLR-11447: ZkStateWriter should process commands in atomic
> ZkStateWriter should process commands in atomic
> -----------------------------------------------
>
> Key: SOLR-11447
> URL: https://issues.apache.org/jira/browse/SOLR-11447
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Cao Manh Dat
> Assignee: Cao Manh Dat
> Attachments: SOLR-11447.patch, SOLR-11447.patch
>
>
> ZkStateWriter should process all the ZkWriteCommands correspond to a message
> in atomic ( we are processing one by one command right now ). Some
> ZkWriteCommands can get lost. Here is the case :
> 1. We process DOWNNODE message ( whatever message that produces multiple
> ZkWriteComand ).
> 2. We poll that message from stateUpdateQueue and push it to workQueue ( for
> backup ).
> 3. The DOWNNODE message is converted into multiple ZkWriteCommand
> 4. We enqueue one by one ZkWriteCommand into ZkStateWriter. Any command can
> trigger flush, which calls the onWrite() callback to empty workQueue
> 5. The Overseer gets restarted, and the rest of ZkWriteCommands (which not
> get processed in step 4) will be lost because the workQueue is empty now
> (because onWrite() callback in step 4)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
