[
https://issues.apache.org/jira/browse/LUCENE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965194#action_12965194
]
Earwin Burrfoot commented on LUCENE-2779:
-----------------------------------------
bq. Cloning the keySet() will be exactly the 'snapshotty' behavior we're
looking for. Before I made the change, you could call listAll(), lock RAMDir,
return the array and before/after that files could be added/removed. W/ the
clone, we'll get the same behavior - files can be added/removed before the
clone, clone would reflect those changes, whatever happens after the clone is
invisible to the iterator - hence why I consider it snapshotty.
There are still weird cases, when file B was added after deleting A, but you
see both in listAll(). These - remain, so it's not a "point in time" it's more
like a "span in time".
Whatever happened after toArray was invisible to array too, so the behaviour
hasn't changed.
bq. Also, what do you know, I've hit an AIOB exception thrown from listAll()
when it called toArray() :)
But _this_ fact is really interesting. toArray() with no parameters failed on
CHM? Cloning has a meaning now :)
bq. Earwin, I did not *just* backport it. ........
Didn't mean to offend anyone, sorry if I did.
> 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]
