Hi, I'm using the one from the map package my import looks like this:
import org.apache.commons.collections.map.LRUMap; As I've seen the LRUMap outside the "map" package is deprecated. René 2009/6/15 Leon Rosenberg <[email protected]>: > weird enough there are two LRUMap classes in commons collections, > org.apache.commons.collections and org.apache.commons.collections.map. > Which one are you using? > > regards > Leon > > On Mon, Jun 15, 2009 at 6:00 PM, Renè Glanzer<[email protected]> wrote: >> 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 <[email protected]>: >>> 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] >>> >>> >> >> --------------------------------------------------------------------- >> 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]
