That's the one, René. Yeah, no real solution in that JIRA issue I'm afraid. :( But it shows you what's already been looked at.
Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Renè Glanzer <[email protected]> > To: Commons Users List <[email protected]> > Sent: Tuesday, June 16, 2009 6:05:26 AM > Subject: Re: [collections] LRUMap Problem ConcurrentModificationException > > Hey Otis, > > i found this one: > https://issues.apache.org/jira/browse/COLLECTIONS-3 > > but there is no solutions only an assumption at the end of the thread?? > > René > > 2009/6/15 Otis Gospodnetic : > > > > Btw. I think you'll find a report about this from a few years ago in the > Collections JIRA. Just search for my name. > > > > Otis > > -- > > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > > > > > > ----- Original Message ---- > >> From: Renè Glanzer > >> To: Commons Users List > >> Sent: Monday, June 15, 2009 12:00:54 PM > >> Subject: Re: [collections] LRUMap Problem ConcurrentModificationException > >> > >> Yes of course, > >> > >> the code with the time based cache systems was set up with an ordniary > >> HashMap. But when rapidly seach requests are > >> generated the time based mechanism fails to delete old entries - cause > >> they are not old enough - and so the cache will > >> raise up until the entire VM memory is used. Then i found the LRUMap > >> switched to it and bang Exception in my delete method. > >> > >> When i switch back to HashMap the code runs well - as currently on the > >> productive system - except the open memory leak. > >> > >> René > >> > >> 2009/6/15 Leon Rosenberg : > >> > 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è Glanzerwrote: > >> >> 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 : > >> >>> 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è Glanzerwrote: > >> >>>> 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 : > >> >>>>> 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: [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] > >> > > >> > > >> > >> --------------------------------------------------------------------- > >> 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]
