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 e
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
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
M
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 wrote:
> I was searching for a very lighweight cache systems with not much overhead
> for my purposes. The LRUMap just matched
> perfect
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
> Or, ehcache or oscache or something like that?
>
> On Wed, Jun 17, 2009 at 10:17 AM, Leon
> Rosenberg wrote:
Or, ehcache or oscache or something like that?
On Wed, Jun 17, 2009 at 10:17 AM, Leon
Rosenberg 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 wrote:
>> Hi,
>>
>> it's me again with an update
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 wrote:
> Hi,
>
> it's me again with an update.
> the LRUMap.mapIterator() still produces the
> ConcurrentModificationException when a call to MapIterator.remove(
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 :
> Hi Jörg,
>
> it's me again. With a smile on my face :-)
>
> I changed my code according
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
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
hist
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
> 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'
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
t; To: Commons Users List
> > 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
> >
>
List
> 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 e
ns 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
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 :
> weird enough there are two LRUMap classes in commons collections,
> org.apa
ne 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 me
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 wrote:
> Yes of course,
>
> the code with the time based cache systems was s
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. The
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 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
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
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 wrote:
> I'm calling the remove() method on the iterator.
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 creat
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
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 p
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
synchroniz
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 th
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
28 matches
Mail list logo
