Re: [collections] LRUMap Problem ConcurrentModificationException

> just out of curiosity have you tried the same code with a standard hashmap?
>
> Leon
>
> On Mon, Jun 15, 2009 at 4:37 PM, Renè Glanzer<rene.glanzer@...> wrote:
>> Hello,
>>
>> side note accepted :-)
>>
>> In my class I checked the get, put and remove methods. All are synchronized.
>> As you can see also the code which wants to delete the elements is synchronized.
>> So I've no clue where the "ConcurrentModificationException" is comming from :-(
>>
>> Thanks René
>>
>> 2009/6/15 Leon Rosenberg <rosenberg.leon@...>:
>>> Hello,
>>>
>>> on a side note, generics make reading of code easier :-)
>>>
>>> you haven't posted the whole code, but have you (double)checked that
>>> all other acesses to store are synchronized?
>>>
>>> regards
>>> Leon
>>>
>>> On Mon, Jun 15, 2009 at 2:31 PM, Renè Glanzer<rene.glanzer@...> wrote:
>>>> I'm calling the remove() method on the iterator. I know when i call
>>>> the remove on the map itself it will cause the problem with my
>>>> currently running iterator, but i'm aware of that.
>>>>
>>>> Here is the code block which should delete old entries:
>>>>
>>>> store: is the LRUMap
>>>> birth: is a long which keeps the creation time when this is set to 0
>>>> the item should be deleted
>>>>
>>>> public void removeAllExpiredItems()
>>>>  {
>>>>   synchronized(this.store)
>>>>   {
>>>>     Iterator it=this.store.keySet().iterator();
>>>>     while(it.hasNext())
>>>>     {
>>>>       Object key=it.next();
>>>>       Object o=this.get(key);
>>>>       if(o != null)
>>>>       {
>>>>         Item iEntry=(Item)this.store.get(key);
>>>>         if(iEntry.birth==0)
>>>>           it.remove(); //Here the exception occurs
>>>>       }
>>>>     }
>>>>     this.setLastCleanDate(new Date()); //only to know when the
>>>> deleter run the last time
>>>>   }
>>>>  }
>>>>
>>>> Thanks for any help :-)
>>>> René
>>>>
>>>> 2009/6/15 James Carman <james@...>:
>>>>> 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@...> 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@...>:
>>>>>>> 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@...>:
>>>>>>>> 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@...> 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@...
>>>>>> For additional commands, e-mail: user-help@...
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-unsubscribe@...
>>>>> For additional commands, e-mail: user-help@...
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@...
>>>> For additional commands, e-mail: user-help@...
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@...
>>> For additional commands, e-mail: user-help@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@...
>> For additional commands, e-mail: user-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>