Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Message-ID: <31250587.24211291128493147.JavaMail.jira@thor>
Date: Tue, 30 Nov 2010 09:48:13 -0500 (EST)
From: "Yonik Seeley (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-2779) Use ConcurrentHashMap in
 RAMDirectory
In-Reply-To: <10750696.314731290706214515.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965240#action_12965240 ] 

Yonik Seeley commented on LUCENE-2779:
--------------------------------------

OK, a few points on the latest patch:
- cloning the map does not change the "lie" (i.e. it's still not a point-in-time snapshot)... the constructor for the new set must iterate over the items also, so consistency is not increased.  You've just changed where the iteration happens.  You can see this by trying out my test program, and making the following change:
{code}
      Object[] vals = map.keySet().toArray(new Integer[0]);
      Object[] vals = new HashSet<String>(map.keySet()).toArray(new Integer[0]);
{code}
- toArray() or toArray(T[]) should be safe to call on ConcurrentHashMap.keySet().  It works fine on my JVM (Oracle Java6)
  What JVM are you using?


> 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