You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mario Ivankovits <im...@apache.org> on 2004/05/10 21:09:58 UTC
[collections] LRUMap wont search next "removeable" entry
Hello!
I tried to use the map.LRUMap but failed by a design issue.
Copied from the test-case:
MockLRUMapSubclassBlocksRemove map = new
MockLRUMapSubclassBlocksRemove(2);
assertEquals(0, map.size());
map.put("A", "a");
assertEquals(1, map.size());
map.put("B", "b");
assertEquals(2, map.size());
map.put("C", "c"); // should remove oldest, which is A=a, but
this is blocked
assertEquals(3, map.size());
assertEquals(2, map.maxSize());
assertEquals(true, map.containsKey("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 current test-case do not handle it (it blocks all entries),
but shouldnt the LRUMap - if an entry is locked - search the next
removeable entry?
At the end, the entries "A" and "C" should be in the map - only if all
entries are lock the map should grow.
I cant derive from LRUMap to overload addMapping - The members "before"
and "after" on LinkEntry are protected and not accessible by the subclass.
-- Mario
Re: [collections] LRUMap wont search next "removeable" entry
Posted by Mario Ivankovits <im...@apache.org>.
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
Hope this is it.
-- Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] BidiMap javadoc typo
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Fixed, thanks
Stephen
----- Original Message -----
From: "Michael Heuer" <he...@acm.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, May 10, 2004 8:44 PM
Subject: [collections] BidiMap javadoc typo
>
> A small typo in the BidiMap javadocs:
>
> $ cvs diff src/java/org/apache/commons/collections/BidiMap.java
> Index: src/java/org/apache/commons/collections/BidiMap.java
> ===================================================================
> RCS file:
>
/home/cvspublic/jakarta-commons/collections/src/java/org/apache/commons/coll
ections/BidiMap.java,v
> retrieving revision 1.15
> diff -r1.15 BidiMap.java
> 23c23
> < * Th interface extends <code>Map</code> and so may be used anywhere a
map
> ---
> > * This interface extends <code>Map</code> and so may be used anywhere a
map
>
> (or Th -> The would work too)
>
> michael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[collections] BidiMap javadoc typo
Posted by Michael Heuer <he...@acm.org>.
A small typo in the BidiMap javadocs:
$ cvs diff src/java/org/apache/commons/collections/BidiMap.java
Index: src/java/org/apache/commons/collections/BidiMap.java
===================================================================
RCS file:
/home/cvspublic/jakarta-commons/collections/src/java/org/apache/commons/collections/BidiMap.java,v
retrieving revision 1.15
diff -r1.15 BidiMap.java
23c23
< * Th interface extends <code>Map</code> and so may be used anywhere a map
---
> * This interface extends <code>Map</code> and so may be used anywhere a map
(or Th -> The would work too)
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] LRUMap wont search next "removeable" entry
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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" <im...@apache.org>
> The problem i have is:
> If i add an entry to the lrumap which is locked, it blocks all other
> entries too - even if they are not blocked.
>
> I think LRUMap.addMapping should scan until it finds an removeable entry:
>
> >The protected restriction on the LinkEntry fields is another problem
fixed
> >in CVS - see the entryAfter() and entryBefore() methods.
> >
> >
> Ah - thanks. Maybe i could implement this behaviour in my subclass.
>
> However - i thought the LRUMap should hold all "LRU" and "Blocked"
> entries - and remove any other entry.
>
> e.g. size = 2
> add blocked A
> add B
> add C
>
> the result should be
> A
> C
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] LRUMap wont search next "removeable" entry
Posted by Mario Ivankovits <im...@apache.org>.
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 is the test
>for the bug, and demonstrates that LRUMap can exceed its size.
>
>
>
The problem i have is:
If i add an entry to the lrumap which is locked, it blocks all other
entries too - even if they are not blocked.
I think LRUMap.addMapping should scan until it finds an removeable entry:
>The protected restriction on the LinkEntry fields is another problem fixed
>in CVS - see the entryAfter() and entryBefore() methods.
>
>
Ah - thanks. Maybe i could implement this behaviour in my subclass.
However - i thought the LRUMap should hold all "LRU" and "Blocked"
entries - and remove any other entry.
e.g. size = 2
add blocked A
add B
add C
the result should be
A
C
-- Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] LRUMap wont search next "removeable" entry
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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 protected restriction on the LinkEntry fields is another problem fixed
in CVS - see the entryAfter() and entryBefore() methods.
Stephen
----- Original Message -----
From: "Mario Ivankovits" <im...@apache.org>
> I tried to use the map.LRUMap but failed by a design issue.
>
> Copied from the test-case:
>
> MockLRUMapSubclassBlocksRemove map = new
> MockLRUMapSubclassBlocksRemove(2);
> assertEquals(0, map.size());
> map.put("A", "a");
> assertEquals(1, map.size());
> map.put("B", "b");
> assertEquals(2, map.size());
> map.put("C", "c"); // should remove oldest, which is A=a, but
> this is blocked
> assertEquals(3, map.size());
> assertEquals(2, map.maxSize());
> assertEquals(true, map.containsKey("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 current test-case do not handle it (it blocks all entries),
> but shouldnt the LRUMap - if an entry is locked - search the next
> removeable entry?
> At the end, the entries "A" and "C" should be in the map - only if all
> entries are lock the map should grow.
>
> I cant derive from LRUMap to overload addMapping - The members "before"
> and "after" on LinkEntry are protected and not accessible by the subclass.
>
>
> -- Mario
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org