lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <>
Subject [jira] Updated: (LUCENE-2779) Use ConcurrentHashMap in RAMDirectory
Date Tue, 30 Nov 2010 09:27:11 GMT


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

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:
>             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,
> 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:
For additional commands, e-mail:

View raw message