[
https://issues.apache.org/jira/browse/LUCENE-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1726:
---------------------------------------
Attachment: LUCENE-1726.patch
Attached new patch (the patch is worse than it looks, because many
things moved into the CoreReaders class):
* Moved more stuff into CoreReaders (fieldInfos, dir, segment, etc.)
and moved methods down as well (ctor, openDocStores, decRef).
* Made members final when possible, else synchronized access to
getting them (to avoid running amok of JMM).
{quote}
Right however wouldn't it be somewhat cleaner to sync on core
for all clone operations given we don't want those to occur
(external to IW) at the same time? Ultimately we want core to be
the controller of it's resources rather than the SR being cloned?
{quote}
In fact, I'm not sure why cloning/reopening a segment needs to be
synchronized at all.
Sure it'd be weird for an app to send multiple threads down,
attempting to reopen/clone the same SR or core at once, but from
Lucene's standpoint there's nothing "wrong" with doing so, I think?
(Though, DirectoryReader does need its sync when its transferring the
write lock due to reopen on a reader w/ pending changes).
{quote}
I ran the test with the SRMapValue sync code, (4 threads) with
the sync on SR.core in openDocStore for 10 minutes, 2 core
Windows XML laptop Java 6.14 and no errors. Then same with 2
threads for 5 minutes and no errors. I'll keep on running it to
see if we can get an error.
{quote}
You could try inserting a testPoint (see the other testPoints in
IndexWriter) after the SRMapValue is pulled from the hash but before
we check if its reader is null, and then modify the threads in your
test to randomly yield on that testPoint (by subclassing IW)? Ie
"exacerbate" the path that exposes the hazard.
{quote}
I'm still a little confused as to why we're going to see the bug
if readerPool.get is syncing on the SRMapValue. I guess there's
a slight possibility of the error, and perhaps a more randomized
test would produce it.
{quote}
The hazard exists because there's a time when no synchronization is
held. Ie, you retrieve SRMapValue from the hash while sync'd on
ReaderPool. You then leave that sync entirely (this is where hazard
comes in), and next you sync on the SRMapValue. Another thread can
sneak in and close the SRMapValue.reader during the time that no sync
is held.
> IndexWriter.readerPool create new segmentReader outside of sync block
> ---------------------------------------------------------------------
>
> Key: LUCENE-1726
> URL: https://issues.apache.org/jira/browse/LUCENE-1726
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Affects Versions: 2.4.1
> Reporter: Jason Rutherglen
> Assignee: Michael McCandless
> Priority: Trivial
> Fix For: 3.1
>
> Attachments: LUCENE-1726.patch, LUCENE-1726.patch, LUCENE-1726.patch,
> LUCENE-1726.patch, LUCENE-1726.patch, LUCENE-1726.patch,
> LUCENE-1726.trunk.test.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> I think we will want to do something like what field cache does
> with CreationPlaceholder for IndexWriter.readerPool. Otherwise
> we have the (I think somewhat problematic) issue of all other
> readerPool.get* methods waiting for an SR to warm.
> It would be good to implement this for 2.9.
--
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
