lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Earwin Burrfoot (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1609) Eliminate synchronization contention on initial index reading in TermInfosReader ensureIndexIsRead
Date Thu, 23 Apr 2009 17:06:30 GMT

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

Earwin Burrfoot commented on LUCENE-1609:
-----------------------------------------

You cannot put all these fields into state object, because you introduce state to it and it
can no longer be unsafely published.

> one thread may exchange the state object to a IndexRead, but another one still sees the
reference to the IndexNotRead object
Nothing terrible here, a thread hitting stale IndexNotRead synchronizes and short-circuits
in the beginning of the method. The problem is that seeing proper state object doesn't guarantee
seeing fields it is supposed to guard :)

Yes, it's not fixable here without volatile or proper synchronization. But I still have a
feeling that lazy loading (and consequent synchronization) is not needed here at all.

> 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
>         Attachments: 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message