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<[email protected]> 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 <[email protected]>: >> 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<[email protected]> 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 <[email protected]>: >>>> Are you calling remove() on the iterator or on the map itself? >>>> >>>> On Mon, Jun 15, 2009 at 6:37 AM, Renè Glanzer<[email protected]> >>>> 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 <[email protected]>: >>>>>> 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 <[email protected]>: >>>>>>> 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 <[email protected]> >>>>>>> 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: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
