Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Tue, 15 Mar 2011 01:40:29 +0000 (UTC)
From: "Earwin Burrfoot (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <1763943332.2612.1300153229791.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1745196938.10551.1299760139433.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Commented: (LUCENE-2960) Allow (or bring back) the ability
 to setRAMBufferSizeMB on an open IndexWriter
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/LUCENE-2960?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D130=
06759#comment-13006759 ]=20

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 wil=
l 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 t=
he many JVM instances on many machines got unlucky after restart.

bq. Well, and, it'd be bad for perf. =E2=80=93 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 fi=
elds 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 al=
l data read from memory.

bq. IWC cannot be made immutable =E2=80=93 you build it up incrementally (n=
ew IWC(...).setThis(...).setThat(...)). Its fields cannot be final.
Setters can return modified immutable copy of 'this'. So you get both incre=
mental building and immutability.

bq. How about this as a compromise: IW continues cloning the incoming IWC o=
n init, as it does today. This means any changes to the IWC instance you pa=
ssed 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 eac=
h and every setting to know if you can change it live or not.

> Allow (or bring back) the ability to setRAMBufferSizeMB on an open IndexW=
riter
> -------------------------------------------------------------------------=
-----
>
>                 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 tr=
unk. It would be great to be able to control that on a live IndexWriter. Ot=
her possible two methods that would be great to bring back are setTermIndex=
Interval and setReaderTermsIndexDivisor. Most of the other setters can actu=
ally 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org