[
https://issues.apache.org/jira/browse/SOLR-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469204
]
Ryan McKinley commented on SOLR-126:
------------------------------------
>
> - 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.
>
I'm looking at it from the client perspective. The timer should start as soon
as close to the request time as possible.
> - 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.
>
I just left at were it was in the existing code. I think it makes sense
because the searcher has the proper data at that point - a second commit wont
change the results.
Also, it will not start a new autocommit until the first has warmed the
searcher anyway:
CommitUpdateCommand command = new CommitUpdateCommand( false );
command.waitFlush = true;
command.waitSearcher = true;
> - 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?
>
This is trying to avoid is the case where 100 documents are added at the same
time with maxDocs=10. We don't want to commit 10 times, so it waits 1/4 sec.
(could be shorter or longer in my opinion)
If anyone is worried about the timing, they should use maxTime, not maxDocs
> 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.
