commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [collections] LRUMap Problem ConcurrentModificationException
Date Mon, 15 Jun 2009 12:13:23 GMT
Are you calling remove() on the iterator or on the map itself?

On Mon, Jun 15, 2009 at 6:37 AM, Renè Glanzer<rene.glanzer@gmail.com> wrote:
> Hello,
>
> is there still no help for me?
> Is somebody able to explain me, why i get this
> "java.util.ConcurrentModificationException"
> on iterating and calling remove() on the LRUMap?
>
> Please
> René
>
> 2009/6/10 Renè Glanzer <rene.glanzer@gmail.com>:
>> Hello Ted,
>>
>> thanks for the fast response. I understand that simultaneously puts
>> and gets do not cause the exception cause they are synchronized in my
>> class.
>> And my stated code-fragment is the part which wants to delete the
>> entries from the underlying LRUMap. And my code is wrapped in the
>> synchronized block. But i think the LRUMap herselfe also iterates the
>> entries and this maybe happens at the same time when my iterator is
>> checking and trying to delete elements. My class is not implementing
>> the LRUMap but has one LRUMap as a variable.
>> So your solution to override the removeLRU(Entry) methode would not
>> help me....unfortunatelly :-(
>>
>> For now i really do not know how to solve the problem in an easy way
>> without refractoring the entire code?
>> Any other solutions?
>> Thanks René
>>
>>
>>
>> 2009/6/9 Ted Dunning <ted.dunning@gmail.com>:
>>> 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, this
>>> may be sufficient.  With very high levels of updates and threading, it would
>>> 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 than
>>> 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è 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.
>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message