[
https://issues.apache.org/jira/browse/LUCENE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-2779:
-------------------------------
Attachment: LUCENE-2779.patch
Attached patch combines the changes to RAMDir and the changes to MockRAMDir
under backwards.
I also made the map final, as Uwe suggested, but it means that on close() it
cannot be nullified, so instead I clear()-ed it. I think it achieves the same
goal - clearing the references to RAMFiles.
Also, what do you know, I've hit an AIOB exception thrown from listAll() when
it called toArray() :). So I cloned the set of keys first, which protects
against it. After the set is cloned, it's not affected by any changes to the
map, and therefore toArray() works safely, and returns some point in time
snapshot of the map. The "point in time" is not necessarily the one that
existed when you called listAll(), but the cloned set becomes the "point in
time" snapshot. I think it's ok.
I've hit it when running backwards tests (from TestIndexWriterExceptions), but
not from core. Perhaps it was just a threading issue.
If you're ok w/ that, I'll make the same changes to trunk as well (making the
map final and cloning the set).
All tests pass (this time, including backwards :)).
> Use ConcurrentHashMap in RAMDirectory
> -------------------------------------
>
> Key: LUCENE-2779
> URL: https://issues.apache.org/jira/browse/LUCENE-2779
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Store
> Reporter: Shai Erera
> Assignee: Shai Erera
> Priority: Minor
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2779-backwardsfix.patch, LUCENE-2779.patch,
> LUCENE-2779.patch, LUCENE-2779.patch, TestCHM.java
>
>
> RAMDirectory synchronizes on its instance in many places to protect access to
> map of RAMFiles, in addition to updating the sizeInBytes member. In many
> places the sync is done for 'read' purposes, while only in few places we need
> 'write' access. This looks like a perfect use case for ConcurrentHashMap
> Also, syncing around sizeInBytes is unnecessary IMO, since it's an AtomicLong
> ...
> I'll post a patch shortly.
--
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: [email protected]
For additional commands, e-mail: [email protected]
