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-2779) Use ConcurrentHashMap in RAMDirectory
Date Tue, 30 Nov 2010 10:54:12 GMT

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


Mime
View raw message