[ 
https://issues.apache.org/jira/browse/LUCENE-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006759#comment-13006759
 ] 

Earwin Burrfoot commented on LUCENE-2960:
-----------------------------------------

bq. infoStream is a PrintStream, which synchronizes anyway, so it should be 
safe to omit the volatile
You're absolutely right here.

bq. Yet, no "real" Java impl out there will ever do this since doing so will 
simply make that Java impl appear buggy.
Sorry, but "real" Java impls do this. The case with endless get() happened on a 
map that was never modified after being created and set. Just one of the many 
JVM instances on many machines got unlucky after restart.

bq. Well, and, it'd be bad for perf. – obviously the Java impl, CPU cache 
levels, should cache only frequently used things
Java impls don't cache things. They do reorderings, they also keep final fields 
on registers, omitting reloads that happen for non-final ones, but no caching 
in JMM-related cases. Caching here is done by CPU, and it caches all data read 
from memory.

bq. IWC cannot be made immutable – you build it up incrementally (new 
IWC(...).setThis(...).setThat(...)). Its fields cannot be final.
Setters can return modified immutable copy of 'this'. So you get both 
incremental building and immutability.

bq. How about this as a compromise: IW continues cloning the incoming IWC on 
init, as it does today. This means any changes to the IWC instance you passed 
to IW will have no effect on IW.
What about earlier compromise mentioned by Shay, Mark, me? Keep setters for 
'live' properties on IW.
This clearly draws the line, and you don't have to consult Javadocs for each 
and every setting to know if you can change it live or not.

> 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
>
>         Attachments: LUCENE-2960.patch
>
>
> 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

Reply via email to