Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Message-ID: <27627945.7841290964177602.JavaMail.jira@thor>
Date: Sun, 28 Nov 2010 12:09:37 -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=12964575#action_12964575 ] 

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

bq. I checked CHM iterators and they are safe w.r.t the map being modified after the iterator was obtained.

Yes, but that wasn't the problem.  The iterator for ketSet "guarantees to traverse elements as they existed upon construction of the iterator".
The real problem is that the String[] is created based on the size of the keySet, and then later, an iterator is created over the keySet.  If an addition to the set is done between those two events, the iterator will traverse more elements than there is room for - hence the AIOB exception.

 bq. About remove I'll have to look in the code (not near the comp now) - but I had a feeling that it is safe too, b/c the file is first removed,

The createOutput issue is that get() was used (not remove) so multiple threads could overwrite the same file and all of them subtract the size.

> 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.patch
>
>
> 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