You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by fr...@apache.org on 2002/01/27 19:46:51 UTC
cvs commit: jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore MRUMap.java
froehlich 02/01/27 10:46:51
Modified: simplestore/src/java/org/apache/commons/simplestore
MRUMap.java
Log:
fixed imports
Revision Changes Path
1.2 +1 -4 jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/MRUMap.java
Index: MRUMap.java
===================================================================
RCS file: /home/cvs/jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/MRUMap.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MRUMap.java 27 Jan 2002 17:41:48 -0000 1.1
+++ MRUMap.java 27 Jan 2002 18:46:50 -0000 1.2
@@ -8,11 +8,8 @@
package org.apache.commons.simplestore;
-import java.util.Set;
-import java.util.Collection;
import java.util.HashMap;
import java.util.LinkedList;
-import java.util.Map;
/**
* This class provides a MRU cache algorithm. It combines a HashMap
@@ -20,7 +17,7 @@
*
* @author Gerhard Froehlich <a href="mailto:g-froehlich@gmx.de">
* g-froehlich@gmx.de</a>
- * @version $Id: MRUMap.java,v 1.1 2002/01/27 17:41:48 froehlich Exp $
+ * @version $Id: MRUMap.java,v 1.2 2002/01/27 18:46:50 froehlich Exp $
*/
public final class MRUMap
extends HashMap {
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: JISP, cache
Posted by Juozas Baliuka <ba...@mwm.lt>.
Hi,
I had plans to integrate it with simplestore, for transactional storage,
but it seems I don't understand license. I know MySQL server use it for
transactional tables.
At 10:08 PM 1/29/2002 -0500, you wrote:
>Thanks for the sleepycat link. Looks good but the license is close to
>GPL. It may be ok if the redistribution clause only goes 1 level. JCS
>would be the app, the app using JCS would not could as redistributing
>sleepycat. I doubt it though.
>
>Aaron
>
> > -----Original Message-----
> > From: Juozas Baliuka [mailto:baliuka@mwm.lt]
> > Sent: Tuesday, January 29, 2002 3:40 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: JISP, cache
> >
> > At 01:33 AM 1/29/2002 -0500, you wrote:
> > >What kind of performance are you getting from JISP?
> > >
> > >For JCS I tried using a generic key that would take a serialized
>object
> > >and compared on the hashcode and the performance is not so great. I
>ran
> > >jprobe on it and the io is the bottleneck. The hashcode was
> > >insignificant. . . . Maybe I'm too tired to see the problem.
> > I don't tried JISP, I think there are a lot of BTree
>implementations,
> > and
> > user
> > can choose one, may be JISP or his implementation. I know NetBeans
>have
> > some implementation
> > may be it is the same JISP, I saw JDO RI use it. Berkeley DB is very
> > powerful for this kind of storage
> > http://sleepycat.com , and believe there are more implementations .
> > But we don't have open source stress tools, I think this is the main
> > problem,
> > I have no budget for simplestore to buy jprobe and its sources.
> >
> >
> >
> >
> > >How much memory is it using for the keys and index?
> > >
> > >Keys are pretty cheap. If you can keep them in memory and store the
> > >values on disk, you can get a tremendous performance boost. I did
>this
> > >for one of the disk cache auxiliaries in JCS. . . .
> >
> > Yes, it is good idea to have index in memory for BTree implementation
> >
> >
> >
> > >Hmmn.
> > >
> > >Aaron
> > >
> > >
> > >
> > >
> > >--
> > >To unsubscribe, e-mail: <mailto:commons-dev->
> unsubscribe@jakarta.apache.org>
> > >For additional commands, e-mail: <mailto:commons-dev->
> help@jakarta.apache.org>
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <mailto:commons-dev->
> unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:commons-dev->
> help@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JISP, cache
Posted by Juozas Baliuka <ba...@mwm.lt>.
Yes, Thank you, JDBM is very interesting, I downloaded it .
At 04:46 PM 1/29/2002 +0100, you wrote:
>On Tue, Jan 29, 2002 at 09:40:26AM +0100, Juozas Baliuka wrote:
> > At 01:33 AM 1/29/2002 -0500, you wrote:
> > >What kind of performance are you getting from JISP?
> > >
> > >For JCS I tried using a generic key that would take a serialized object
> > >and compared on the hashcode and the performance is not so great. I ran
> > >jprobe on it and the io is the bottleneck. The hashcode was
> > >insignificant. . . . Maybe I'm too tired to see the problem.
> > I don't tried JISP, I think there are a lot of BTree implementations,
> and
> > user
> > can choose one, may be JISP or his implementation. I know NetBeans have
> > some implementation
> > may be it is the same JISP, I saw JDO RI use it. Berkeley DB is very
> > powerful for this kind of storage
> > http://sleepycat.com , and believe there are more implementations .
>
>On of them is on the sourceforge and has a BSD licence:
>
>http://jdbm.sourceforge.net/
>
>You can see two examples of it's use, one of the is an object cache.
>
>incze
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: JISP, cache
Posted by Aaron Smuts <aa...@verizon.net>.
Ya. I've seen this. I'll take another look.
Aaron
> -----Original Message-----
> From: Incze Lajos [mailto:incze@mail.matav.hu]
> Sent: Tuesday, January 29, 2002 10:47 AM
> To: Jakarta Commons Developers List
> Subject: Re: JISP, cache
>
> On Tue, Jan 29, 2002 at 09:40:26AM +0100, Juozas Baliuka wrote:
> > At 01:33 AM 1/29/2002 -0500, you wrote:
> > >What kind of performance are you getting from JISP?
> > >
> > >For JCS I tried using a generic key that would take a serialized
object
> > >and compared on the hashcode and the performance is not so great.
I
> ran
> > >jprobe on it and the io is the bottleneck. The hashcode was
> > >insignificant. . . . Maybe I'm too tired to see the problem.
> > I don't tried JISP, I think there are a lot of BTree
implementations,
> and
> > user
> > can choose one, may be JISP or his implementation. I know NetBeans
have
> > some implementation
> > may be it is the same JISP, I saw JDO RI use it. Berkeley DB is very
> > powerful for this kind of storage
> > http://sleepycat.com , and believe there are more implementations .
>
> On of them is on the sourceforge and has a BSD licence:
>
> http://jdbm.sourceforge.net/
>
> You can see two examples of it's use, one of the is an object cache.
>
> incze
>
> --
> To unsubscribe, e-mail: <mailto:commons-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JISP, cache
Posted by Incze Lajos <in...@mail.matav.hu>.
On Tue, Jan 29, 2002 at 09:40:26AM +0100, Juozas Baliuka wrote:
> At 01:33 AM 1/29/2002 -0500, you wrote:
> >What kind of performance are you getting from JISP?
> >
> >For JCS I tried using a generic key that would take a serialized object
> >and compared on the hashcode and the performance is not so great. I ran
> >jprobe on it and the io is the bottleneck. The hashcode was
> >insignificant. . . . Maybe I'm too tired to see the problem.
> I don't tried JISP, I think there are a lot of BTree implementations, and
> user
> can choose one, may be JISP or his implementation. I know NetBeans have
> some implementation
> may be it is the same JISP, I saw JDO RI use it. Berkeley DB is very
> powerful for this kind of storage
> http://sleepycat.com , and believe there are more implementations .
On of them is on the sourceforge and has a BSD licence:
http://jdbm.sourceforge.net/
You can see two examples of it's use, one of the is an object cache.
incze
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: JISP, cache
Posted by Aaron Smuts <aa...@verizon.net>.
Thanks for the sleepycat link. Looks good but the license is close to
GPL. It may be ok if the redistribution clause only goes 1 level. JCS
would be the app, the app using JCS would not could as redistributing
sleepycat. I doubt it though.
Aaron
> -----Original Message-----
> From: Juozas Baliuka [mailto:baliuka@mwm.lt]
> Sent: Tuesday, January 29, 2002 3:40 AM
> To: Jakarta Commons Developers List
> Subject: Re: JISP, cache
>
> At 01:33 AM 1/29/2002 -0500, you wrote:
> >What kind of performance are you getting from JISP?
> >
> >For JCS I tried using a generic key that would take a serialized
object
> >and compared on the hashcode and the performance is not so great. I
ran
> >jprobe on it and the io is the bottleneck. The hashcode was
> >insignificant. . . . Maybe I'm too tired to see the problem.
> I don't tried JISP, I think there are a lot of BTree
implementations,
> and
> user
> can choose one, may be JISP or his implementation. I know NetBeans
have
> some implementation
> may be it is the same JISP, I saw JDO RI use it. Berkeley DB is very
> powerful for this kind of storage
> http://sleepycat.com , and believe there are more implementations .
> But we don't have open source stress tools, I think this is the main
> problem,
> I have no budget for simplestore to buy jprobe and its sources.
>
>
>
>
> >How much memory is it using for the keys and index?
> >
> >Keys are pretty cheap. If you can keep them in memory and store the
> >values on disk, you can get a tremendous performance boost. I did
this
> >for one of the disk cache auxiliaries in JCS. . . .
>
> Yes, it is good idea to have index in memory for BTree implementation
>
>
>
> >Hmmn.
> >
> >Aaron
> >
> >
> >
> >
> >--
> >To unsubscribe, e-mail: <mailto:commons-dev-
> unsubscribe@jakarta.apache.org>
> >For additional commands, e-mail: <mailto:commons-dev-
> help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:commons-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JISP, cache
Posted by Juozas Baliuka <ba...@mwm.lt>.
At 01:33 AM 1/29/2002 -0500, you wrote:
>What kind of performance are you getting from JISP?
>
>For JCS I tried using a generic key that would take a serialized object
>and compared on the hashcode and the performance is not so great. I ran
>jprobe on it and the io is the bottleneck. The hashcode was
>insignificant. . . . Maybe I'm too tired to see the problem.
I don't tried JISP, I think there are a lot of BTree implementations, and
user
can choose one, may be JISP or his implementation. I know NetBeans have
some implementation
may be it is the same JISP, I saw JDO RI use it. Berkeley DB is very
powerful for this kind of storage
http://sleepycat.com , and believe there are more implementations .
But we don't have open source stress tools, I think this is the main problem,
I have no budget for simplestore to buy jprobe and its sources.
>How much memory is it using for the keys and index?
>
>Keys are pretty cheap. If you can keep them in memory and store the
>values on disk, you can get a tremendous performance boost. I did this
>for one of the disk cache auxiliaries in JCS. . . .
Yes, it is good idea to have index in memory for BTree implementation
>Hmmn.
>
>Aaron
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
JISP, cache
Posted by Aaron Smuts <aa...@verizon.net>.
What kind of performance are you getting from JISP?
For JCS I tried using a generic key that would take a serialized object
and compared on the hashcode and the performance is not so great. I ran
jprobe on it and the io is the bottleneck. The hashcode was
insignificant. . . . Maybe I'm too tired to see the problem.
How much memory is it using for the keys and index?
Keys are pretty cheap. If you can keep them in memory and store the
values on disk, you can get a tremendous performance boost. I did this
for one of the disk cache auxiliaries in JCS. . . .
Hmmn.
Aaron
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>