DO NOT REPLY [Bug 38753] - [collections] LRUMap loses values when resizing.

NVALID --- Additional Comments From [EMAIL PROTECTED] 2006-02-22 17:47 --- This appears to not be a problem with LRUMap. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug,

DO NOT REPLY [Bug 38753] - [collections] LRUMap loses values when resizing.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 38753] - [collections] LRUMap loses values when resizing.

gzilla/show_bug.cgi?id=38753 [EMAIL PROTECTED] changed: What|Removed |Added Summary|LRUMap looses values when |[collections] LRUMap loses |re

DO NOT REPLY [Bug 38753] New: - LRUMap looses values when resizing.

gzilla/show_bug.cgi?id=38753 Summary: LRUMap looses values when resizing. Product: Commons Version: 3.1 Platform: PC OS/Version: Windows XP Status: NEW Severity: critical Priority: P2 Component: Colle

Re: [Collections] PB with LRUMap serialization

LRUMaps. > > I am performing the following operations in my code: > 1) If serialized file exists, deserialize LRUMap > 2) Fill LRUMap > 3) Serialize LRUMap to file > > I run my program several times, and the memory is > growing over and over > at each run ! After 10 runs

[Collections] PB with LRUMap serialization

Hi all I have met a strange problem while serializing/deserializing LRUMaps. I am performing the following operations in my code: 1) If serialized file exists, deserialize LRUMap 2) Fill LRUMap 3) Serialize LRUMap to file I run my program several times, and the memory is growing over and over

DO NOT REPLY [Bug 28887] - add flag to LRUMap to allow scan of next removeable entry

gzilla/show_bug.cgi?id=28887 add flag to LRUMap to allow scan of next removeable entry [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RE

Re: [collections] LRUMap wont search next "removeable" entry

Stephen Colebourne schrieb: I didn't originally plan for the behaviour you describe, however it does make sense. Perhaps you might try patching the existing LRUMap with a boolean flag to enable this 'scan' behaviour. http://issues.apache.org/bugzilla/show_bug.cgi?id=28887

DO NOT REPLY [Bug 28887] - add flag to LRUMap to allow scan of next removeable entry

gzilla/show_bug.cgi?id=28887 add flag to LRUMap to allow scan of next removeable entry --- Additional Comments From [EMAIL PROTECTED] 2004-05-10 20:05 --- Created an attachment (id=11505) [PATCH] Add flag scanUntilRemoveable and te

DO NOT REPLY [Bug 28887] New: - add flag to LRUMap to allow scan of next removeable entry

gzilla/show_bug.cgi?id=28887 add flag to LRUMap to allow scan of next removeable entry Summary: add flag to LRUMap to allow scan of next removeable entry Product: Commons Version: unspecified Platform: Other OS/Version:

Re: [collections] LRUMap wont search next "removeable" entry

I didn't originally plan for the behaviour you describe, however it does make sense. Perhaps you might try patching the existing LRUMap with a boolean flag to enable this 'scan' behaviour. Stephen From: "Mario Ivankovits" <[EMAIL PROTECTED]> > The problem i h

Re: [collections] LRUMap wont search next "removeable" entry

Stephen Colebourne schrieb: I'm not sure I quite follow ;-) There was a bug in the 3.0 LRUMap which caused the wrong map entry to be passed to the protected method handling deletion. However this is fixed in CVS. Yes - i catched this bug and use the cvs version now. The test case you show i

Re: [collections] LRUMap wont search next "removeable" entry

I'm not sure I quite follow ;-) There was a bug in the 3.0 LRUMap which caused the wrong map entry to be passed to the protected method handling deletion. However this is fixed in CVS. The test case you show is the test for the bug, and demonstrates that LRUMap can exceed its size. The prot

[collections] LRUMap wont search next "removeable" entry

tainsKey("A")); assertEquals(true, map.containsKey("B")); assertEquals(true, map.containsKey("C")); The interesting part is "map.put("C", "c"); //* should remove oldest, which is A=a, but this is blocked*". Even it the curren

Re: [collections] LRUMap - which order?

Done, and its not a hack as thats what the superclass did anyway :-) Stephen - Original Message - From: "Morgan Delagrange" <[EMAIL PROTECTED]> > Makes sense to me, as long as it doesn't turn into a > hack. You'll probably want to update the Javadocs > too, if that's the behaviour you w

Re: [collections] LRUMap - which order?

[EMAIL PROTECTED] wrote: Just to confirm, you want map.firstKey() to return the next key to be removed from the map? Stephen Correct, I think this makes the most sense. Anyone else have an opinion? - To unsubscribe, e-mail: [

Re: [collections] LRUMap - which order?

Just to confirm, you want map.firstKey() to return the next key to be removed from the map? Stephen > from:__matthewHawthorne <[EMAIL PROTECTED]> > I think eldest first makes more sense, based on the nature of the class. > > > > > Stephen Colebourne wrote:

Re: [collections] LRUMap - which order?

I think eldest first makes more sense, based on the nature of the class. Stephen Colebourne wrote: The old LRUMap ordered the elements eldest to newest in the iterator. The new LRUMap does the opposite. Should we be sticking to the eldest first ordering? Or is newest first a better more

[collections] LRUMap - which order?

The old LRUMap ordered the elements eldest to newest in the iterator. The new LRUMap does the opposite. Should we be sticking to the eldest first ordering? Or is newest first a better more sensible ordering? Stephen - To

LRUMap

I have been using org.apache.commons.collections.LRUMap for a wile now and it works fine. In the current implementation, the size of the LRUMap (which determines if it has reached its maximum limit) is just the number of elements in the map. I want to assign each object in the LRUMap an integer

DO NOT REPLY [Bug 9719] - Minor problems in SequencedHashMap and LRUMap

gzilla/show_bug.cgi?id=9719 Minor problems in SequencedHashMap and LRUMap [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Reso

DO NOT REPLY [Bug 9719] New: - Minor problems in SequencedHashMap and LRUMap

gzilla/show_bug.cgi?id=9719 Minor problems in SequencedHashMap and LRUMap Summary: Minor problems in SequencedHashMap and LRUMap Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity:

[collections] LRUMap javadoc patch

+++ LRUMap.java 16 Apr 2002 20:12:27 - @@ -82,7 +82,7 @@ * * * - * Unlike that Collections 1.0 version, this version of LRUMap does use a true + * Unlike the Collections 1.0 version, this version of LRUMap does use a true * LRU algorithm. The keys for all gets and puts are moved to the

RE: [collections][PATCH] LRUMap - license, docs update

t; Subject: Re: [collections][PATCH] LRUMap - license, docs update > > - Original Message - > From: "Michael Smith" <[EMAIL PROTECTED]> > > > Maybe renaming it to FastLRUMap that approximates LRU but > > > isn't totally > > > accurat

Re: [collections][PATCH] LRUMap - license, docs update

On Fri, 15 Feb 2002, Morgan Delagrange wrote: > IMO, moving an item to the front upon any get or put is precisely what is > implied by LRU. I think someone may want to take on a LFUMap class too, but > that's much more complicated. agreed. I'm tempted to take on an LFUMap, but haven't had the t

Re: [collections][PATCH] LRUMap - license, docs update

- Original Message - From: "James Strachan" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; "Morgan Delagrange" <[EMAIL PROTECTED]> Sent: Friday, February 15, 2002 10:47 AM Subject: Re: [collections][PATCH]

Re: [collections][PATCH] LRUMap - license, docs update

- Original Message - From: "Morgan Delagrange" <[EMAIL PROTECTED]> > - Original Message - > From: "Michael Smith" <[EMAIL PROTECTED]> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > Sent: Friday, February

Re: [collections][PATCH] LRUMap - license, docs update

- Original Message - From: "Michael Smith" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Friday, February 15, 2002 7:41 AM Subject: RE: [collections][PATCH] LRUMap - license, docs update > -Original Message-

RE: [collections][PATCH] LRUMap - license, docs update

> -Original Message- > From: James Strachan [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 15, 2002 10:28 AM > To: Jakarta Commons Developers List > Subject: Re: [collections][PATCH] LRUMap - license, docs update > > > Can I get commit access to collecti

Re: [collections][PATCH] LRUMap - license, docs update

> Can I get commit access to collections if it is going there? I'm sure you could. You're already a jakarta committer right? (Turbine-stratum?) So it'd just take a vote to get karma I think James _ Do You Yahoo!? Get your free @yahoo.

RE: [collections][PATCH] LRUMap - license, docs update

Can I get commit access to collections if it is going there? > -Original Message- > From: James Strachan [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 15, 2002 10:04 AM > To: Jakarta Commons Developers List > Subject: Re: [collections][PATCH] LRUMap - license, docs u

Re: [collections][PATCH] LRUMap - license, docs update

From: "Aaron Smuts" <[EMAIL PROTECTED]> > I think that this would mostly involve changing the name and adding a few > simple methods. Cool. > How does something get to collections? Just submit a patch. Hopefully Michael will be a committer soon so he'll probably jump in and apply it first ;-)

RE: [collections][PATCH] LRUMap - license, docs update

s Developers List > Subject: Re: [collections][PATCH] LRUMap - license, docs update > > From: "Aaron Smuts" <[EMAIL PROTECTED]> > > Or you could use what I put in stratum. > > You mean LRUStore thats in the org.apache.stratum.util.lru package? If so > it&#x

RE: [collections][PATCH] LRUMap - license, docs update

we're really kind of stuck with the name. We'll need to maintain the name for Collections 1.x to maintain API compatibility. Morgan has done a little work on LRUMap recently. I haven't gotten the chance to take a peek, but maybe he fixed the bubble list so it really is a leas

Re: [Collections] subclassing LRUMap

On Thu, 14 Feb 2002, Morgan Delagrange wrote: > > I don't know if you saw these other messages talking about LRUMap > > (there's more, I just selected a couple): > > > > http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg02555.html > >

Re: [Collections] subclassing LRUMap

- Original Message - From: "Michael A. Smith" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; "Morgan Delagrange" <[EMAIL PROTECTED]> Sent: Thursday, February 14, 2002 3:49 PM Subject: Re: [Collections] su

Re: [Collections] subclassing LRUMap

On Thu, 14 Feb 2002, Morgan Delagrange wrote: > I just made a backward-compatible change to LRUMap to facilitate > subclassing. Now, you can override removeLRU() if you want to manipulate > (e.g. persist to disk) an Object before it is automatically removed from the > Map. You can a

Re: [Collections] subclassing LRUMap

rsday, February 14, 2002 3:26 PM Subject: RE: [Collections] subclassing LRUMap > You need a special removal for overflow since you don't want to spoll normal > removals to disk. The LRU implementation in stratum allows you to do this. > > > -Original Message- > > F

RE: [Collections] subclassing LRUMap

> To: Jakarta Commons Developers > Subject: [Collections] subclassing LRUMap > > Hi all, > > I just made a backward-compatible change to LRUMap to facilitate > subclassing. Now, you can override removeLRU() if you want to manipulate > (e.g. persist to disk) an Object before

[Collections] subclassing LRUMap

Hi all, I just made a backward-compatible change to LRUMap to facilitate subclassing. Now, you can override removeLRU() if you want to manipulate (e.g. persist to disk) an Object before it is automatically removed from the Map. You can also subclass remove(Object) if you want to manipulate all

RE: [collections][PATCH] LRUMap - license, docs update

From: James Strachan [mailto:[EMAIL PROTECTED]] > I've also been pondering a solution to the LRU issue that > preserves the > efficiency of the bubble list (and avoids expensive tree or > count-indexing > data structuers) but solves the problem that Aaron found. > Still not had any > bright ideas

Re: [collections][PATCH] LRUMap - license, docs update

it to FastLRUMap that approximates LRU but isn't totally accurate in all circumstances might help? James - Original Message - From: "Michael Smith" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Sunday, February 10, 2002 5:

[collections][PATCH] LRUMap - license, docs update

email from Aaron Smuts: http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg02555.ht ml The approach in LRUMap may have been at attempt at a "most used" where the most used element is at the front of the list, but it fails to do that as well. An alternative data structure that m

RE: [collections][PATCH] SequencedHashMap violates Map contract, has poor performance -- BufferCache, SequencedHastable, MRUMap and LRUMap .

SequencedHastable, MRUMap and LRUMap > . > > Aaron Smuts [mailto:[EMAIL PROTECTED]] wrote: > > I'm looking for new memory management algorithms for JCS. The LRU I'm > > using, which is basically the LRUStore I added, is good, but I'd like > > somethi

RE: [collections][PATCH] SequencedHashMap violates Map contract, has poor performance -- BufferCache, SequencedHastable, MRUMap and LRUMap .

Aaron Smuts [mailto:[EMAIL PROTECTED]] wrote: > I'm looking for new memory management algorithms for JCS. The LRU I'm > using, which is basically the LRUStore I added, is good, but I'd like > something more efficient for huge collections of objects. Basically, > every get results in a reshufflin

RE: [collections][PATCH] SequencedHashMap violates Map contract, has poor performance -- BufferCache, SequencedHastable, MRUMap and LRUMap .

nce -- BufferCache, SequencedHastable, MRUMap and LRUMap > . > > > > ok. I've looked over some of the classes you mentioned. LRUMap in > > > commons.collections definately suffers the same problems. I'm about > > > to post a patch for that class that enumera

RE: [collections][PATCH] SequencedHashMap violates Map contract, has poor performance -- BufferCache, SequencedHastable, MRUMap and LRUMap .

> > ok. I've looked over some of the classes you mentioned. LRUMap in > > commons.collections definately suffers the same problems. I'm about > > to post a patch for that class that enumerates some of the > > problems that I > > saw (I didn't fix t

RE: [collections][PATCH] SequencedHashMap violates Map contract, has poor performance -- BufferCache, SequencedHastable, MRUMap and LRUMap .

SequencedHastable, MRUMap and LRUMap > . > > > I was talking about the one in cvs. I was trying to point > > out that there > > are other classes that suffer from the same problem that you > > are fixing and > > that there are other problems with one of the LRU &

[collections][PATCH] LRUMap - license, docs update

e implementation in this email from Aaron Smuts: http://www.mail-archive.com/commons-dev%40jakarta.apache.org/msg02555.ht ml The approach in LRUMap may have been at attempt at a "most used" where the most used element is at the front of the list, but it fails to do that as well. A

RE: [collections][PATCH] SequencedHashMap violates Map contract, has poor performance -- BufferCache, SequencedHastable, MRUMap and LRUMap .

d over some of the classes you mentioned. LRUMap in commons.collections definately suffers the same problems. I'm about to post a patch for that class that enumerates some of the problems that I saw (I didn't fix them yet -- the patch just changes the license to the proper long form an

RE: [collections][PATCH] SequencedHashMap violates Map contract, has poor performance -- BufferCache, SequencedHastable, MRUMap and LRUMap .

; From: Michael A. Smith [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 01, 2002 10:46 AM > To: Jakarta Commons Developers List > Subject: RE: [collections][PATCH] SequencedHashMap violates Map contract, > has poor performance -- BufferCache, SequencedHastable, MRUMap and LRUMap >

RE: [collections][PATCH] SequencedHashMap violates Map contract, has poor performance -- BufferCache, SequencedHastable, MRUMap and LRUMap.

rating the problems with existing CVS version. Stratum is some component in turbine, right? I'm not that familiar with it. I did see your post here about it though, and plan on commenting on it this evening or tomorrow when I have some more time. > LRUMap in Collections looks pre

RE: [collections][PATCH] SequencedHashMap violates Map contract, has poor performance -- BufferCache, SequencedHastable, MRUMap and LRUMap.

27;s sequence. keySequence.remove(key); } keySequence.add(key); } I suspect it has O(N) linear performance degredation. LRUMap in Collections looks pretty good. I'm going to test it. Most LRU moves the most recently used to the top. LRU just pushes an elemen

Re: LRUMap has interesting behavior, not quite LRU

I haven't observed this, but I haven't really used LRUMap that extensively either. It seems that nobody replied to this message. Has anyone else observed this? Just curious. Otis On Wed, 09 January 2002, "apache-commons" wrote: > > Commons developers, > &

LRUMap has interesting behavior, not quite LRU

latest in cvs. LRUMap.java is from version 1.1. Further I have noticed that if you remove an item, the "bubbling up" stops at that removed item. Simple test, put the following code fragment into LRUMap and run: BTW - I found an old copy of: org/apache/tomcat/util/LRUCache.java, whic