[
https://issues.apache.org/jira/browse/LUCENE-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-2163:
---------------------------------------
Attachment: LUCENE-2163.patch
We've made awesome progress removing sync'd, now that SR is read-only ... but I
found a few remaining sync'd in StandardDirectoryReader that I *think* are not
necessary?
Eg doClose is already protected by IR.close (only one thread will decRef to
RC=0).
And for doOpenIfChanged/noWriter... why do they need to be sync'd? If it's
solely to prevent strange exceptions when one thread is closing while another
is reopening ... I don't think we need to do that (it's "best effort", and I
think likely you'd get ACE anyway since we'd try to incRef an already-closed
SR)?
But then again I suppose the sync'd are not really hurting anything (it won't
block searches since nothing else is sync'd...). Still it's nice to remove
them if we can, in case something on the search path does become sync'd at some
point ...
> Remove synchronized from DirReader.reopen/clone
> -----------------------------------------------
>
> Key: LUCENE-2163
> URL: https://issues.apache.org/jira/browse/LUCENE-2163
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
> Reporter: Michael McCandless
> Priority: Minor
> Fix For: 4.1
>
> Attachments: LUCENE-2163.patch
>
>
> Spinoff from LUCENE-2161, where the fact that DirReader.reopen is
> sync'd was dangerous in the context of NRT (could block all searches
> against that reader when CMS was throttling). So, with LUCENE-2161,
> we're removing the synchronization when it's an NRT reader that you're
> reopening.
> But... why should we sync even for a "normal" reopen? There are
> various sync'd methods on IndexReader/DirReader (we are reducing that,
> with LUCENE-2161 and also LUCENE-2156), but, in general it doesn't
> seem like "normal" reopen really needs to be sync'd. Performing a reopen
> shouldn't incur any chance of blocking a search...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
