[
https://issues.apache.org/jira/browse/SOLR-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469187
]
Mike Klaas commented on SOLR-126:
---------------------------------
Ryan: looking good! A few comments:
- You notify the tracker that the document is added before actually adding the
document. This is okay--commit() cannot run until addDoc() is complete--but it
does mean that the autocommit maxTime is measured from the start of the
document being added until after it has been processed. I'm not sure it
matters in practice.
- similarly, didCommit() is invoked before the searcher is warmed. Autocommits
will never occur simulatneously (as you note; due to synchronization of run()),
but they could be invoked continually if warming takes a long time.
- If 250ms is a small enough time to not care about, does it make sense to
force the user to specify the time in milliseconds?
These are all relatively minor things--if no one else has any thoughts this can
probably be committed soon.
> Auto-commit documents after time interval
> -----------------------------------------
>
> Key: SOLR-126
> URL: https://issues.apache.org/jira/browse/SOLR-126
> Project: Solr
> Issue Type: Improvement
> Components: update
> Reporter: Ryan McKinley
> Priority: Minor
> Attachments: AutoCommit.patch, AutocommitingUpdateRequestHandler.patch
>
>
> If an index is getting updated from multiple sources and needs to add
> documents reasonably quickly, there should be a good solr side mechanism to
> help prevent the client from spawning multiple overlapping <commit/> commands.
> My specific use case is sending each document to solr every time hibernate
> saves an object (see SOLR-20). This happens from multiple machines
> simultaneously. I'd like solr to make sure the documents are committed
> within a second.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
