[
https://issues.apache.org/jira/browse/SOLR-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899130#action_12899130
]
Hoss Man commented on SOLR-1990:
--------------------------------
Note: the entire premise of the code in question, that updates w/o documents
should "blockUntilFinished" because "this happens for commit" makes no sense to
me.
In the Runnable where requests that do make it into the queue are processed,
there is code that explicitly checks for requests which include the "commit" or
"optimize" params and those are processed as part of the stream -- w/o blocking.
So why should a "commit" by itself block, but an update doc that includes an
"optimize" not block?
> blockUntilFinished() is called in StreamingUpdateSolrServer more often then
> it should
> -------------------------------------------------------------------------------------
>
> Key: SOLR-1990
> URL: https://issues.apache.org/jira/browse/SOLR-1990
> Project: Solr
> Issue Type: Bug
> Components: clients - java
> Affects Versions: 1.4.1
> Reporter: ofer fort
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> in the StreamingUpdateSolrServer .request() it identifies a commit/optimize
> request by having no document...
> {code}
> // this happens for commit...
> if( req.getDocuments()==null || req.getDocuments().isEmpty() ) {
> blockUntilFinished();
> {code}
> ...but there are other situations where an UpdateRequest will nave no
> documents (delete, updates using stream.url or stream.file, etc...)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
