Are you calling remove() on the iterator or on the map itself? On Mon, Jun 15, 2009 at 6:37 AM, Renč 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 : >> 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 : >>> 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 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