[
https://issues.apache.org/jira/browse/LUCENE-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716593#action_12716593
]
Michael McCandless commented on LUCENE-1609:
--------------------------------------------
I agree we could ship 2.9 without this fix (in fact I think most of
the issues marked 2.9 could be postponed until 3.x), but...
Because the ability of the JRE to downgrade an inflated lock back to a
lightweight lock seems to be very implementation/version dependent,
coupled with the fact that term info lookup is very frequently called
(especially for MultiTermQuery), makes me think this is indeed
something rather important to fix.
And a nice side effect of up-front init is that it front-loads
initialization more, ie, the work is done in IndexReader.open instead
of the first query. (Other things, like populating FieldCache,
loading norms, still happen on the first query of course...).
bq. A much better application fix is to simply limit the number of threads
executing queries.
Well... if your hardware has concurrency, is it really the case that
Lucene never gets in the way? I'd love to see this confirmed
empirically. Ie you should ideally be able to run as many threads as
will saturate your hardware, and see it scale properly.
> Eliminate synchronization contention on initial index reading in
> TermInfosReader ensureIndexIsRead
> ---------------------------------------------------------------------------------------------------
>
> Key: LUCENE-1609
> URL: https://issues.apache.org/jira/browse/LUCENE-1609
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Affects Versions: 2.9
> Environment: Solr
> Tomcat 5.5
> Ubuntu 2.6.20-17-generic
> Intel(R) Pentium(R) 4 CPU 2.80GHz, 2Gb RAM
> Reporter: Dan Rosher
> Assignee: Michael McCandless
> Fix For: 2.9
>
> Attachments: LUCENE-1609.patch, LUCENE-1609.patch
>
>
> synchronized method ensureIndexIsRead in TermInfosReader causes contention
> under heavy load
> Simple to reproduce: e.g. Under Solr, with all caches turned off, do a simple
> range search e.g. id:[0 TO 999999] on even a small index (in my case 28K
> docs) and under a load/stress test application, and later, examining the
> Thread dump (kill -3) , many threads are blocked on 'waiting for monitor
> entry' to this method.
> Rather than using Double-Checked Locking which is known to have issues, this
> implementation uses a state pattern, where only one thread can move the
> object from IndexNotRead state to IndexRead, and in doing so alters the
> objects behavior, i.e. once the index is loaded, the index nolonger needs a
> synchronized method.
> In my particular test, this uncreased throughput at least 30 times.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
