Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.217.206 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=NGHDDw6wM8Qf4DpXVNBKBu5SkhgYuF1NjshlmxtMjU6lzwYfyJj+nsxfCQsJ81R8BZ
         GaNpW/ZDoVjm22xFxDcP6kvUBFlMnepR36XOHXReRyr8fvtH4WQIb3XawxAbt7QwG5yW
         SyHpwL64qsyy0AYxTpDvPHanBN29/SZa41psY=
MIME-Version: 1.0
In-Reply-To: <4fc6b7820906090933tf707810xce8470c2614784cd@mail.gmail.com>
References: <4fc6b7820906090933tf707810xce8470c2614784cd@mail.gmail.com>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Tue, 9 Jun 2009 10:39:23 -0700
Message-ID: <c7d45fc70906091039h2f1db75etdac41d0c539bed30@mail.gmail.com>
Subject: Re: [collections] LRUMap Problem ConcurrentModificationException
To: Commons Users List <user@commons.apache.org>
Content-Type: multipart/alternative; boundary=000e0cd487d20e8b4b046bedd849

--000e0cd487d20e8b4b046bedd849
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I apologize for not reading your thread with great care, but I think that
your problem is pretty clear.

The issue is not to do with gets and puts overlapping.  The issue is that a
put or remove happened during the life of your iterator.

One way to avoid this is to synchronize the entire method that does the
deletion of old elements.  To speed that up, you might just synchronize the
scan for elements to delete and collect them into a list.  Then you can
delete them outside the loop.  Since your scan is probably pretty fast, thi=
s
may be sufficient.  With very high levels of updates and threading, it woul=
d
cause problems.

Another option is to clone the table.  I believe that some implementations
of LRUMap in Lucene do copy-on-write semantics, but I don't think that
collections has these.  Without that, cloning will be as slow or slower tha=
n
your scan so the first option would be better.

I am curious, however, why you didn't make use of the built-in capabilities
of the LRUMap to help you with this.  Notably, you should probably just
over-ride the removeLRU(Entry) method and set the scanUntilRemovable flag.
I think that this would take the place of your loop and would be much more
efficient.

On Tue, Jun 9, 2009 at 9:33 AM, Ren=C3=A8 Glanzer <rene.glanzer@gmail.com> =
wrote:

> ... Additionally to the maximum number of the LRUMap i also implemented a
> thread which periodicly checks the age of the entries and deletes them
> when they are too old.
>
> For this i generated an Iterator which delivers me each entry and if
> the creation date is too old i call iterator.remove().
> But exactly on this line i get an
> "java.util.ConcurrentModificationException" although i wrapped all
> access to the map with synchronized blocks. So every put and get
> methods are synchronized.
>
>

--000e0cd487d20e8b4b046bedd849--