Perhaps instead of "recordTimeSec = System.nanoTime()/1000000000.0;" you can use TimeUnit.NANOS.toSeconds? Just for clarity, and get rid of this monstrous number .
I was wanting to have the seconds be a double, but, I agree that's
overkill; I think a "typical" pruning time should be maybe 10 minutes
and so having "int seconds" is OK. I'll change it and use
Typo: "such that if the use performs": 'use' --> 'user'
Thanks I'll fix.
Would it be better if SearcherTracker has a close() method and we call it instead of decRef()-ing on our own?
I agree – I'll fix.
About this "// nocommit – maybe make it 'public' that you just decRef?" --> do you mean whether we should jdoc that that's all we're doing? If so, why commit to just that? I don't think it contributes to the user ...
Well... the release is sort of "spooky" in that you can freely call it after close, which is why I thought about making its impl public; but I agree, let's leave it private and just keep the NOTE that it's fine to call after close.
I have a problem with the Pruner interface. It has a single method prune which takes an IndexSearcher and ageSec (BTW, why is it double and not long?). And there's PruneByAge impl. But, what other impls could there be for this interface, if not by age?
On the other hand, I can certainly see someone, perhaps w/ NRT, not wanting to keep too many searchers around, and instead of committing to an age, he'll want to use a hard number (like, the newest 5 searchers) - that interface makes it impossible to impl.
If you think however that pruning by age, is the only scenario that makes sense, then I suggest removing the interface and having just the impl. Otherwise, perhaps a different interface should be created, one that receives a list of searchers, with their age, and returns a list of searchers that should be released? Just an idea.
Hmm, now that I read prune(Pruner) jdoc, I can see how someone could impl "newest 5 searchers" by just counting up to 5 in its doPrune() calls, because prune(Pruner) guarantees that the searchers are passed newest to oldest. But still I wonder if the interface is not too limited.
Right, my idea was to make it really easy to prune-by-age, since
that's the common case, but also make it possible to do more
I think prune-by-count is possible, but maybe more interesting would
be prune-by-total-segments-size, ie, if a large merge commits, this
metric would cut back on the number of searchers so that the net RAM
tied up is lower. Not sure this is really needed in practice as large
merges don't complete often and it's unlikely you'd hit more than one in
your time window...