[
https://issues.apache.org/jira/browse/SOLR-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899739#action_12899739
]
Ryan McKinley commented on SOLR-1990:
-------------------------------------
IIRC, the big picture intention is that <commit/> with the
StreamingUpdateSolrServer should behave the same as <commit/> with the other
(non-streaming) implementations. People using the implementation should not
need to know to blockUntilFinished() for commit to work properly.
It seem the check should be:
{code:java}
if( req.getAction() != null ) {
blockUntilFinished();
}
{code}
Though it may be good to try and avoid the two map lookups for every request:
{code:java}
public ACTION getAction() {
if (params==null) return null;
if (params.getBool(UpdateParams.COMMIT, false)) return ACTION.COMMIT;
if (params.getBool(UpdateParams.OPTIMIZE, false)) return ACTION.OPTIMIZE;
return null;
}
{code}
> 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: [email protected]
For additional commands, e-mail: [email protected]
