> - 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