You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2016/02/03 00:54:40 UTC

[jira] [Updated] (SOLR-8633) DistributedUpdateProcess.processCommit calls finish() - violates lifecycle, causes finish to be called twice (redundent code execution)

     [ https://issues.apache.org/jira/browse/SOLR-8633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hoss Man updated SOLR-8633:
---------------------------
    Attachment: SOLR-8633.patch

attaching a strawman patch that has asserts ensuring that {{finish()}} is never called more then once on either DUP or SolrCmdDistributor, and makes {{blockAndDoRetries()}} public so DUP can call it instead of {{finish()}}

all tests pass ... anyone see any problems with this? 

any reason why the previous code (where all the logic in DUP.finish() was getting executed twice when there was an explicit commit) was better/needed ?

> DistributedUpdateProcess.processCommit calls finish() - violates lifecycle, causes finish to be called twice (redundent code execution)
> ---------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-8633
>                 URL: https://issues.apache.org/jira/browse/SOLR-8633
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: SOLR-8633.patch
>
>
> trying to wrap my head around a weird bug in my experiements with SOLR-445, i realized that {{DUP.processDelete}} has a direct call to {{finish()}}.
> This violates the normal lifecycle of an UpdateProcessor (finish is only suppose to be called exactly once after processing any/all UpdateCommands) and could potentially break any UpdateProcessors configured after DUP (or in my case: processors configured _before_ DUP that expect to be in charge of calling finish, and catching any resulting exceptions, as part of the normal life cycle)
> Independent of how it impacts other update processors, this also means that:
> # all the logic in {{DUP.doFinish}} is getting executed twice -- which seems kind of expensive/dangerous to me since there is leader initiated recovery involved in this method
> # {{SolrCmdDistributor.finish()}} gets called twice, which means {{StreamingSolrClients.shutdown()}} gets called twice, which means {{ConcurrentUpdateSolrClient.close()}} gets called twice ... it seems like we're just getting really lucky that (as configured by DUP) all of these resources are still usable after being finished/shutdown/closed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org