[
https://issues.apache.org/jira/browse/LUCENE-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006105#comment-13006105
]
Michael McCandless commented on LUCENE-2960:
--------------------------------------------
bq. If I had to choose between being able to change things in real time to
better concurrency thanks to immutability, I would definitely go with better
concurrency.
We're not talking about better concurrency here -- making these fields
volatile will be in the noise.
If ever it were not in the noise, I agree better concurrency should
win.
bq. I don't think we are talking about that many setter to begin with (I don't
think we should bring those back to the IndexWriter).
True, but we are setting a precedent here. Ie this will apply to
further settings we add to IWC, apply to any other classes that we
pull config out of (eg IR), etc. I don't like that factoring out
config means loss of functionality.
bq. It should not be consulted once the construction phase of IW is done.
Why such purity? What do we gain?
I'm all for purity, but only if it doesn't interfere w/ functionality.
Here, it's taking away freedom...
I would prefer to have the config you passed into IW remain "live".
You can also do IW.getConfig().setXXX later too.
In fact it should be fine to share an IWC across multiple writers; you
can change the RAM buffer for all of them at once.
bq. If explicit real time parameters are to be set, then IW should expose it as
a setter.
But then whenever we change our mind about liveness, we have to change
the API? I'd like to decouple liveness of a setter (really a semantic
aspect of that API, documented in the jdocs) from which API is used to
set it.
I think a config param should be live by default and only if there's
some hardship / reason to not have it so, should we make an
exception. Most of these params are trivial to be live (they were
before the IWC change).
bq. making nonvolatile mutable references introduces you to a world of
hard-to-catch unsafe publication bugs (yes, infoStream is currently broken!).
Well, in theory, yes, in practice, no. This is like stating your HTML is
buggy because it fails to put a closing </html> tag and so some
browser could fail to render it ;)
I doubt there's any JVM out there where our lack-of-volatile
infoStream causes any problems.
But, of course, we should make them volatile to be safe...
bq. Each and every live reconfigurable setting adds to complexity.
That's the exception not the rule. Most of these settings are used at
certain times -- on flushing a new seg, on warming a seg, etc. -- and
there's no added complexity to simply pulling their current value from
the config.
bq. For more complex cases, certain on-change logic is required.
For such cases we can state that changes to the config do not take
effect; eg IndexingChain is a good example I think. But I think the
default should be that changes are live, unless otherwise stated
I don't think we should go out of our way to be making settings live,
if there's any hair involved. But for the settings where there's no
hair involved, they should be live.
> Allow (or bring back) the ability to setRAMBufferSizeMB on an open IndexWriter
> ------------------------------------------------------------------------------
>
> Key: LUCENE-2960
> URL: https://issues.apache.org/jira/browse/LUCENE-2960
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Shay Banon
> Priority: Blocker
> Fix For: 3.1, 4.0
>
>
> In 3.1 the ability to setRAMBufferSizeMB is deprecated, and removed in trunk.
> It would be great to be able to control that on a live IndexWriter. Other
> possible two methods that would be great to bring back are
> setTermIndexInterval and setReaderTermsIndexDivisor. Most of the other
> setters can actually be set on the MergePolicy itself, so no need for setters
> for those (I think).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
