You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Renè Glanzer <re...@gmail.com> on 2009/06/09 18:33:12 UTC
[collections] LRUMap Problem ConcurrentModificationException
Hello,
I us a LRUMap for caching search results from the database. To limit
the maximum number of searches cached i store them in a LRUMap. Also
the timestamp when the entry was put to the map is stored.
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.
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
}
}
Somebody able to help me?
Thank with regards
René
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Leon Rosenberg <ro...@googlemail.com>.
Well, I hope your hash function is well thought through :-)
otherwise using hashmap for caching might be a mess....
On Wed, Jun 17, 2009 at 4:30 PM, Renè Glanzer<re...@gmail.com> wrote:
> I was searching for a very lighweight cache systems with not much overhead
> for my purposes. The LRUMap just matched
> perfectly except the little iterator problem.
>
>
> 2009/6/17 James Carman <ja...@carmanconsulting.com>
>
>> Or, ehcache or oscache or something like that?
>>
>> On Wed, Jun 17, 2009 at 10:17 AM, Leon
>> Rosenberg<ro...@googlemail.com> wrote:
>> > why don't you just use softreference + expiration timestamp and save
>> > all the trouble?
>> > Leon
>> >
>> > On Wed, Jun 17, 2009 at 4:07 PM, Renè Glanzer<re...@gmail.com>
>> wrote:
>> >> Hi,
>> >>
>> >> it's me again with an update.
>> >> the LRUMap.mapIterator() still produces the
>> >> ConcurrentModificationException when a call to MapIterator.remove()
>> >> occurs.
>> >>
>> >> Maybe this info helps
>> >> René
>> >>
>> >>
>> >> 2009/6/17 Renè Glanzer <re...@gmail.com>:
>> >>> Hi Jörg,
>> >>>
>> >>> it's me again. With a smile on my face :-)
>> >>>
>> >>> I changed my code according to your hint.
>> >>> Now i don't use the keySet but the entrySet. With only to adopt the
>> rest of
>> >>> the method to the entrySet and still
>> >>> calling the remove() method of the iterator in my tests no
>> >>> ConcurrentModificationException occured!!
>> >>>
>> >>> Additionally now I'm using the LURMap.mapIterator() which also performs
>> well
>> >>> and according to the docu should be prefered over the entrySet or
>> keySet.
>> >>>
>> >>> Now the new an well working code looks like this:
>> >>>
>> >>> public void removeAllExpiredItems()
>> >>> {
>> >>> synchronized(this.store)
>> >>> {
>> >>> MapIterator it=this.store.mapIterator(); //Here I'm using the new
>> >>> MapIterator
>> >>> while(it.hasNext())
>> >>> {
>> >>> m_catLog.debug("Reading object");
>> >>> Object key=it.next();
>> >>> Item currentItem=(Item)it.getValue();
>> >>> if(currentItem.birth==0)
>> >>> {
>> >>> m_catLog.debug("0 birth found for key "+key+" calling
>> >>> Iterator.remove");
>> >>> it.remove();
>> >>> }
>> >>> }
>> >>> this.setLastCleanDate(new Date());
>> >>> }
>> >>> }
>> >>>
>> >>> Thousand Thanks for your help Jörg
>> >>> this fixed my Problem and maybe also fixes the problems from the other
>> >>> people who suffered the same problem.
>> >>> Furthermore I'm pleased to see that the JIRA issue COLLECTION-330 is
>> >>> handling the problem with the keySet call.
>> >>>
>> >>> 2009/6/17 Jörg Schaible <jo...@gmx.de>
>> >>>>
>> >>>> Renè Glanzer wrote at Mittwoch, 17. Juni 2009 11:48:
>> >>>>
>> >>>> > Hi Jörg,
>> >>>> >
>> >>>> > that are great news, I'll give it a try.
>> >>>> > And of course I'll report my experience.
>> >>>>
>> >>>> That would be fine. Actually I opened an own JIRA issue for this now
>> >>>> (COLLECTION-330), COLLECTION-3 was simply too vague and had a too long
>> >>>> history of different symptoms.
>> >>>>
>> >>>> - Jörg
>> >>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> 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
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Renè Glanzer <re...@gmail.com>.
I was searching for a very lighweight cache systems with not much overhead
for my purposes. The LRUMap just matched
perfectly except the little iterator problem.
2009/6/17 James Carman <ja...@carmanconsulting.com>
> Or, ehcache or oscache or something like that?
>
> On Wed, Jun 17, 2009 at 10:17 AM, Leon
> Rosenberg<ro...@googlemail.com> wrote:
> > why don't you just use softreference + expiration timestamp and save
> > all the trouble?
> > Leon
> >
> > On Wed, Jun 17, 2009 at 4:07 PM, Renè Glanzer<re...@gmail.com>
> wrote:
> >> Hi,
> >>
> >> it's me again with an update.
> >> the LRUMap.mapIterator() still produces the
> >> ConcurrentModificationException when a call to MapIterator.remove()
> >> occurs.
> >>
> >> Maybe this info helps
> >> René
> >>
> >>
> >> 2009/6/17 Renè Glanzer <re...@gmail.com>:
> >>> Hi Jörg,
> >>>
> >>> it's me again. With a smile on my face :-)
> >>>
> >>> I changed my code according to your hint.
> >>> Now i don't use the keySet but the entrySet. With only to adopt the
> rest of
> >>> the method to the entrySet and still
> >>> calling the remove() method of the iterator in my tests no
> >>> ConcurrentModificationException occured!!
> >>>
> >>> Additionally now I'm using the LURMap.mapIterator() which also performs
> well
> >>> and according to the docu should be prefered over the entrySet or
> keySet.
> >>>
> >>> Now the new an well working code looks like this:
> >>>
> >>> public void removeAllExpiredItems()
> >>> {
> >>> synchronized(this.store)
> >>> {
> >>> MapIterator it=this.store.mapIterator(); //Here I'm using the new
> >>> MapIterator
> >>> while(it.hasNext())
> >>> {
> >>> m_catLog.debug("Reading object");
> >>> Object key=it.next();
> >>> Item currentItem=(Item)it.getValue();
> >>> if(currentItem.birth==0)
> >>> {
> >>> m_catLog.debug("0 birth found for key "+key+" calling
> >>> Iterator.remove");
> >>> it.remove();
> >>> }
> >>> }
> >>> this.setLastCleanDate(new Date());
> >>> }
> >>> }
> >>>
> >>> Thousand Thanks for your help Jörg
> >>> this fixed my Problem and maybe also fixes the problems from the other
> >>> people who suffered the same problem.
> >>> Furthermore I'm pleased to see that the JIRA issue COLLECTION-330 is
> >>> handling the problem with the keySet call.
> >>>
> >>> 2009/6/17 Jörg Schaible <jo...@gmx.de>
> >>>>
> >>>> Renè Glanzer wrote at Mittwoch, 17. Juni 2009 11:48:
> >>>>
> >>>> > Hi Jörg,
> >>>> >
> >>>> > that are great news, I'll give it a try.
> >>>> > And of course I'll report my experience.
> >>>>
> >>>> That would be fine. Actually I opened an own JIRA issue for this now
> >>>> (COLLECTION-330), COLLECTION-3 was simply too vague and had a too long
> >>>> history of different symptoms.
> >>>>
> >>>> - Jörg
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> 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
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by James Carman <ja...@carmanconsulting.com>.
Or, ehcache or oscache or something like that?
On Wed, Jun 17, 2009 at 10:17 AM, Leon
Rosenberg<ro...@googlemail.com> wrote:
> why don't you just use softreference + expiration timestamp and save
> all the trouble?
> Leon
>
> On Wed, Jun 17, 2009 at 4:07 PM, Renè Glanzer<re...@gmail.com> wrote:
>> Hi,
>>
>> it's me again with an update.
>> the LRUMap.mapIterator() still produces the
>> ConcurrentModificationException when a call to MapIterator.remove()
>> occurs.
>>
>> Maybe this info helps
>> René
>>
>>
>> 2009/6/17 Renè Glanzer <re...@gmail.com>:
>>> Hi Jörg,
>>>
>>> it's me again. With a smile on my face :-)
>>>
>>> I changed my code according to your hint.
>>> Now i don't use the keySet but the entrySet. With only to adopt the rest of
>>> the method to the entrySet and still
>>> calling the remove() method of the iterator in my tests no
>>> ConcurrentModificationException occured!!
>>>
>>> Additionally now I'm using the LURMap.mapIterator() which also performs well
>>> and according to the docu should be prefered over the entrySet or keySet.
>>>
>>> Now the new an well working code looks like this:
>>>
>>> public void removeAllExpiredItems()
>>> {
>>> synchronized(this.store)
>>> {
>>> MapIterator it=this.store.mapIterator(); //Here I'm using the new
>>> MapIterator
>>> while(it.hasNext())
>>> {
>>> m_catLog.debug("Reading object");
>>> Object key=it.next();
>>> Item currentItem=(Item)it.getValue();
>>> if(currentItem.birth==0)
>>> {
>>> m_catLog.debug("0 birth found for key "+key+" calling
>>> Iterator.remove");
>>> it.remove();
>>> }
>>> }
>>> this.setLastCleanDate(new Date());
>>> }
>>> }
>>>
>>> Thousand Thanks for your help Jörg
>>> this fixed my Problem and maybe also fixes the problems from the other
>>> people who suffered the same problem.
>>> Furthermore I'm pleased to see that the JIRA issue COLLECTION-330 is
>>> handling the problem with the keySet call.
>>>
>>> 2009/6/17 Jörg Schaible <jo...@gmx.de>
>>>>
>>>> Renè Glanzer wrote at Mittwoch, 17. Juni 2009 11:48:
>>>>
>>>> > Hi Jörg,
>>>> >
>>>> > that are great news, I'll give it a try.
>>>> > And of course I'll report my experience.
>>>>
>>>> That would be fine. Actually I opened an own JIRA issue for this now
>>>> (COLLECTION-330), COLLECTION-3 was simply too vague and had a too long
>>>> history of different symptoms.
>>>>
>>>> - Jörg
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Leon Rosenberg <ro...@googlemail.com>.
why don't you just use softreference + expiration timestamp and save
all the trouble?
Leon
On Wed, Jun 17, 2009 at 4:07 PM, Renè Glanzer<re...@gmail.com> wrote:
> Hi,
>
> it's me again with an update.
> the LRUMap.mapIterator() still produces the
> ConcurrentModificationException when a call to MapIterator.remove()
> occurs.
>
> Maybe this info helps
> René
>
>
> 2009/6/17 Renè Glanzer <re...@gmail.com>:
>> Hi Jörg,
>>
>> it's me again. With a smile on my face :-)
>>
>> I changed my code according to your hint.
>> Now i don't use the keySet but the entrySet. With only to adopt the rest of
>> the method to the entrySet and still
>> calling the remove() method of the iterator in my tests no
>> ConcurrentModificationException occured!!
>>
>> Additionally now I'm using the LURMap.mapIterator() which also performs well
>> and according to the docu should be prefered over the entrySet or keySet.
>>
>> Now the new an well working code looks like this:
>>
>> public void removeAllExpiredItems()
>> {
>> synchronized(this.store)
>> {
>> MapIterator it=this.store.mapIterator(); //Here I'm using the new
>> MapIterator
>> while(it.hasNext())
>> {
>> m_catLog.debug("Reading object");
>> Object key=it.next();
>> Item currentItem=(Item)it.getValue();
>> if(currentItem.birth==0)
>> {
>> m_catLog.debug("0 birth found for key "+key+" calling
>> Iterator.remove");
>> it.remove();
>> }
>> }
>> this.setLastCleanDate(new Date());
>> }
>> }
>>
>> Thousand Thanks for your help Jörg
>> this fixed my Problem and maybe also fixes the problems from the other
>> people who suffered the same problem.
>> Furthermore I'm pleased to see that the JIRA issue COLLECTION-330 is
>> handling the problem with the keySet call.
>>
>> 2009/6/17 Jörg Schaible <jo...@gmx.de>
>>>
>>> Renè Glanzer wrote at Mittwoch, 17. Juni 2009 11:48:
>>>
>>> > Hi Jörg,
>>> >
>>> > that are great news, I'll give it a try.
>>> > And of course I'll report my experience.
>>>
>>> That would be fine. Actually I opened an own JIRA issue for this now
>>> (COLLECTION-330), COLLECTION-3 was simply too vague and had a too long
>>> history of different symptoms.
>>>
>>> - Jörg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Jörg Schaible <jo...@gmx.de>.
Renè Glanzer wrote at Mittwoch, 17. Juni 2009 20:09:
> I only gave it a short test. Then i found the MapIterator in the docs an
> switched to it.
> The docs stated that MapIterator is the better way than entrySet.
> Sorry for this, I'm at home right now so i can test it with an entrySet at
> the earliest tomorrow.
The mapIterator fails for me also in the unit tests.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Renè Glanzer <re...@gmail.com>.
I only gave it a short test. Then i found the MapIterator in the docs an
switched to it.
The docs stated that MapIterator is the better way than entrySet.
Sorry for this, I'm at home right now so i can test it with an entrySet at
the earliest tomorrow.
Looking forward to report the result.
2009/6/17 Jörg Schaible <jo...@gmx.de>
> Renè Glanzer wrote at Mittwoch, 17. Juni 2009 16:07:
>
> > Hi,
> >
> > it's me again with an update.
> > the LRUMap.mapIterator() still produces the
> > ConcurrentModificationException when a call to MapIterator.remove()
> > occurs.
>
> So did you also try with the entrySet? I've not written a unit test for the
> MapIterator, so I cannot say, what you should expect... :)
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Jörg Schaible <jo...@gmx.de>.
Renè Glanzer wrote at Mittwoch, 17. Juni 2009 16:07:
> Hi,
>
> it's me again with an update.
> the LRUMap.mapIterator() still produces the
> ConcurrentModificationException when a call to MapIterator.remove()
> occurs.
So did you also try with the entrySet? I've not written a unit test for the
MapIterator, so I cannot say, what you should expect... :)
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Renè Glanzer <re...@gmail.com>.
Hi,
it's me again with an update.
the LRUMap.mapIterator() still produces the
ConcurrentModificationException when a call to MapIterator.remove()
occurs.
Maybe this info helps
René
2009/6/17 Renè Glanzer <re...@gmail.com>:
> Hi Jörg,
>
> it's me again. With a smile on my face :-)
>
> I changed my code according to your hint.
> Now i don't use the keySet but the entrySet. With only to adopt the rest of
> the method to the entrySet and still
> calling the remove() method of the iterator in my tests no
> ConcurrentModificationException occured!!
>
> Additionally now I'm using the LURMap.mapIterator() which also performs well
> and according to the docu should be prefered over the entrySet or keySet.
>
> Now the new an well working code looks like this:
>
> public void removeAllExpiredItems()
> {
> synchronized(this.store)
> {
> MapIterator it=this.store.mapIterator(); //Here I'm using the new
> MapIterator
> while(it.hasNext())
> {
> m_catLog.debug("Reading object");
> Object key=it.next();
> Item currentItem=(Item)it.getValue();
> if(currentItem.birth==0)
> {
> m_catLog.debug("0 birth found for key "+key+" calling
> Iterator.remove");
> it.remove();
> }
> }
> this.setLastCleanDate(new Date());
> }
> }
>
> Thousand Thanks for your help Jörg
> this fixed my Problem and maybe also fixes the problems from the other
> people who suffered the same problem.
> Furthermore I'm pleased to see that the JIRA issue COLLECTION-330 is
> handling the problem with the keySet call.
>
> 2009/6/17 Jörg Schaible <jo...@gmx.de>
>>
>> Renè Glanzer wrote at Mittwoch, 17. Juni 2009 11:48:
>>
>> > Hi Jörg,
>> >
>> > that are great news, I'll give it a try.
>> > And of course I'll report my experience.
>>
>> That would be fine. Actually I opened an own JIRA issue for this now
>> (COLLECTION-330), COLLECTION-3 was simply too vague and had a too long
>> history of different symptoms.
>>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Renè Glanzer <re...@gmail.com>.
Hi Jörg,
it's me again. With a smile on my face :-)
I changed my code according to your hint.
Now i don't use the keySet but the entrySet. With only to adopt the rest of
the method to the entrySet and still
calling the remove() method of the iterator in my tests no
ConcurrentModificationException occured!!
Additionally now I'm using the LURMap.mapIterator() which also performs well
and according to the docu should be prefered over the entrySet or keySet.
Now the new an well working code looks like this:
public void removeAllExpiredItems()
{
synchronized(this.store)
{
MapIterator it=this.store.mapIterator(); //Here I'm using the new
MapIterator
while(it.hasNext())
{
m_catLog.debug("Reading object");
Object key=it.next();
Item currentItem=(Item)it.getValue();
if(currentItem.birth==0)
{
m_catLog.debug("0 birth found for key "+key+" calling
Iterator.remove");
it.remove();
}
}
this.setLastCleanDate(new Date());
}
}
Thousand Thanks for your help Jörg
this fixed my Problem and maybe also fixes the problems from the other
people who suffered the same problem.
Furthermore I'm pleased to see that the JIRA issue COLLECTION-330 is
handling the problem with the keySet call.
2009/6/17 Jörg Schaible <jo...@gmx.de>
> Renè Glanzer wrote at Mittwoch, 17. Juni 2009 11:48:
>
> > Hi Jörg,
> >
> > that are great news, I'll give it a try.
> > And of course I'll report my experience.
>
> That would be fine. Actually I opened an own JIRA issue for this now
> (COLLECTION-330), COLLECTION-3 was simply too vague and had a too long
> history of different symptoms.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Jörg Schaible <jo...@gmx.de>.
Renè Glanzer wrote at Mittwoch, 17. Juni 2009 11:48:
> Hi Jörg,
>
> that are great news, I'll give it a try.
> And of course I'll report my experience.
That would be fine. Actually I opened an own JIRA issue for this now
(COLLECTION-330), COLLECTION-3 was simply too vague and had a too long
history of different symptoms.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Renè Glanzer <re...@gmail.com>.
Hi Jörg,
that are great news, I'll give it a try.
And of course I'll report my experience.
René
2009/6/17 Jörg Schaible <jo...@gmx.de>
> Hi Renè,
>
> Renè Glanzer wrote at Mittwoch, 17. Juni 2009 09:47:
>
> > OK so my search will continue :-)
> > Meanwhile I'll consider to change my implementation, which i'd like to
> > prevent.
>
> I've reopened COLLECTIONS-3, since I was able to write a unit test that
> reproduces the problem.
>
> > Maybe somebody of you knows a time and size based cache system where i
> can
> > map a key to an object?
>
> My enhancement of the unit test for the LRUMap shows, that the
> ConcurrentModificationException only happens, if you use an iterator form
> the keySet. So you should simply use the entrySet in your code and you'll
> be fine.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Renè,
Renè Glanzer wrote at Mittwoch, 17. Juni 2009 09:47:
> OK so my search will continue :-)
> Meanwhile I'll consider to change my implementation, which i'd like to
> prevent.
I've reopened COLLECTIONS-3, since I was able to write a unit test that
reproduces the problem.
> Maybe somebody of you knows a time and size based cache system where i can
> map a key to an object?
My enhancement of the unit test for the LRUMap shows, that the
ConcurrentModificationException only happens, if you use an iterator form
the keySet. So you should simply use the entrySet in your code and you'll
be fine.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Renè Glanzer <re...@gmail.com>.
OK so my search will continue :-)
Meanwhile I'll consider to change my implementation, which i'd like to
prevent.
Maybe somebody of you knows a time and size based cache system where i can
map a key to an object?
René
2009/6/16 Otis Gospodnetic <ot...@yahoo.com>
>
> 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 <re...@gmail.com>
> > To: Commons Users List <us...@commons.apache.org>
> > 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: 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
> > >> >>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>>
> ---------------------------------------------------------------------
> > >> >>>> 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
> > >> >>>
> > >> >>>
> > >> >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> 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
> > >> >
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Otis Gospodnetic <ot...@yahoo.com>.
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 <re...@gmail.com>
> To: Commons Users List <us...@commons.apache.org>
> 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: 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
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>> ---------------------------------------------------------------------
> >> >>>> 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
> >> >>>
> >> >>>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> 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
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Renè Glanzer <re...@gmail.com>.
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 <ot...@yahoo.com>:
>
> 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 <re...@gmail.com>
>> To: Commons Users List <us...@commons.apache.org>
>> 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: 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
>> >>>>>
>> >>>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> 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
>> >>>
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Otis Gospodnetic <ot...@yahoo.com>.
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 <re...@gmail.com>
> To: Commons Users List <us...@commons.apache.org>
> 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: 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
> >>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> 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
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Renè Glanzer <re...@gmail.com>.
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 <ro...@googlemail.com>:
> 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<re...@gmail.com> 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 <ro...@googlemail.com>:
>>> 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<re...@gmail.com> 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 <ro...@googlemail.com>:
>>>>> 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<re...@gmail.com> 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 <ja...@carmanconsulting.com>:
>>>>>>> Are you calling remove() on the iterator or on the map itself?
>>>>>>>
>>>>>>> On Mon, Jun 15, 2009 at 6:37 AM, Renè Glanzer<re...@gmail.com> 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 <re...@gmail.com>:
>>>>>>>>> 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 <te...@gmail.com>:
>>>>>>>>>> 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 <re...@gmail.com> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Leon Rosenberg <ro...@googlemail.com>.
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<re...@gmail.com> 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 <ro...@googlemail.com>:
>> 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<re...@gmail.com> 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 <ro...@googlemail.com>:
>>>> 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<re...@gmail.com> 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 <ja...@carmanconsulting.com>:
>>>>>> Are you calling remove() on the iterator or on the map itself?
>>>>>>
>>>>>> On Mon, Jun 15, 2009 at 6:37 AM, Renè Glanzer<re...@gmail.com> 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 <re...@gmail.com>:
>>>>>>>> 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 <te...@gmail.com>:
>>>>>>>>> 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 <re...@gmail.com> 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
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Renè Glanzer <re...@gmail.com>.
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 <ro...@googlemail.com>:
> 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<re...@gmail.com> 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 <ro...@googlemail.com>:
>>> 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<re...@gmail.com> 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 <ja...@carmanconsulting.com>:
>>>>> Are you calling remove() on the iterator or on the map itself?
>>>>>
>>>>> On Mon, Jun 15, 2009 at 6:37 AM, Renè Glanzer<re...@gmail.com> 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 <re...@gmail.com>:
>>>>>>> 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 <te...@gmail.com>:
>>>>>>>> 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 <re...@gmail.com> 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
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Leon Rosenberg <ro...@googlemail.com>.
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<re...@gmail.com> 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 <ro...@googlemail.com>:
>> 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<re...@gmail.com> 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 <ja...@carmanconsulting.com>:
>>>> Are you calling remove() on the iterator or on the map itself?
>>>>
>>>> On Mon, Jun 15, 2009 at 6:37 AM, Renè Glanzer<re...@gmail.com> 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 <re...@gmail.com>:
>>>>>> 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 <te...@gmail.com>:
>>>>>>> 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 <re...@gmail.com> 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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Renè Glanzer <re...@gmail.com>.
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 <ro...@googlemail.com>:
> 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<re...@gmail.com> 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 <ja...@carmanconsulting.com>:
>>> Are you calling remove() on the iterator or on the map itself?
>>>
>>> On Mon, Jun 15, 2009 at 6:37 AM, Renè Glanzer<re...@gmail.com> 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 <re...@gmail.com>:
>>>>> 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 <te...@gmail.com>:
>>>>>> 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 <re...@gmail.com> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Leon Rosenberg <ro...@googlemail.com>.
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<re...@gmail.com> 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 <ja...@carmanconsulting.com>:
>> Are you calling remove() on the iterator or on the map itself?
>>
>> On Mon, Jun 15, 2009 at 6:37 AM, Renè Glanzer<re...@gmail.com> 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 <re...@gmail.com>:
>>>> 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 <te...@gmail.com>:
>>>>> 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 <re...@gmail.com> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Renè Glanzer <re...@gmail.com>.
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 <ja...@carmanconsulting.com>:
> Are you calling remove() on the iterator or on the map itself?
>
> On Mon, Jun 15, 2009 at 6:37 AM, Renè Glanzer<re...@gmail.com> 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 <re...@gmail.com>:
>>> 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 <te...@gmail.com>:
>>>> 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 <re...@gmail.com> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by James Carman <ja...@carmanconsulting.com>.
Are you calling remove() on the iterator or on the map itself?
On Mon, Jun 15, 2009 at 6:37 AM, Renè Glanzer<re...@gmail.com> 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 <re...@gmail.com>:
>> 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 <te...@gmail.com>:
>>> 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 <re...@gmail.com> 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
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Renè Glanzer <re...@gmail.com>.
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 <re...@gmail.com>:
> 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 <te...@gmail.com>:
>> 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 <re...@gmail.com> 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
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Renè Glanzer <re...@gmail.com>.
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 <te...@gmail.com>:
> 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 <re...@gmail.com> 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
Re: [collections] LRUMap Problem ConcurrentModificationException
Posted by Ted Dunning <te...@gmail.com>.
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 <re...@gmail.com> 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.
>
>