On Mon, 2002-04-29 at 16:05, Weaver, Scott wrote:
> Hi,
>
> 1) Is there anyway to retrieve a collection of all of the keys for a
> particular
> cache region?
You can get a list of all keys in the memory cache by using its iterator
method. That iterates Map.Entrys where they key is the cache key and the
value is a MemoryElementDescriptor.
Aux caches are a little trickier, but the disk aux keeps its keys in
memory so there should be a way.
I use a little pull tool that does the following to inspect the memory
cache:
public List getKeysInMemory( Cache cache )
{
MemoryCache memCache = cache.getMemoryCache();
Iterator iter = memCache.getIterator();
LinkedList list = new LinkedList();
Map.Entry entry;
Pair pair;
while ( iter.hasNext() )
{
pair = new Pair();
entry = ( Map.Entry ) iter.next();
pair.key = entry.getKey();
pair.value =
( ( MemoryElementDescriptor ) entry.getValue() ).ce.getVal();
list.add( pair );
}
return list;
}
> 2) What is the easiest way to determine the size (in bytes) of particular
> cache region.
Um... for the memory cache I do this:
public int getByteCount( Cache cache )
throws Exception
{
MemoryCache memCache = cache.getMemoryCache();
Iterator iter = memCache.getIterator();
CountingOnlyOutputStream counter = new CountingOnlyOutputStream();
ObjectOutputStream out = new ObjectOutputStream( counter );
while ( iter.hasNext() )
{
MemoryElementDescriptor node = ( MemoryElementDescriptor )
( ( Map.Entry ) iter.next() ).getValue();
out.writeObject( node.ce.getVal() );
}
// 4 bytes lost for the serialization header
return counter.getCount() - 4;
}
And counting only output stream is this silly thing:
private static class CountingOnlyOutputStream extends OutputStream
{
private int count;
public void write( byte[] b ) throws IOException
{
count += b.length;
}
public void write( byte[] b, int off, int len ) throws IOException
{
count += len;
}
public void write( int b ) throws IOException
{
count++;
}
/**
* The number of bytes that have passed through this stream.
*/
public int getCount()
{
return this.count;
}
}
Don't know if that's the best way but that's what I do. I'd like to say
that it is potentially really slow and I try not to run it often, but in
reality it takes no time, I can run it on all of my (two or three dozen)
cache regions which total are holding about 40 megs, and it's faster
than I can time.
>
> 3) I am having problems building new JCS now that it has been moved out of
> stratum and is a Maven project.
>
> [javac]
> C:\Java\jakarta-turbine-jcs\src\java\org\apache\jcs\JCSComponent.jav
> a:18: org.apache.jcs.JCSComponent should be declared abstract; it does not
> defin
> e configure(org.apache.stratum.configuration.Configuration) in
> org.apache.jcs.JC
> SComponent
> [javac] public class JCSComponent
> [javac] ^
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -deprecation for details.
> [javac] 1 error
>
> BUILD FAILED
>
> The issue is coming from the fact that Maven needs to use the old stratum.
> This in turn causes the JCS build to puke do to the fact it expects the
> interface org.apache.stratum.lifecycle.Configurable's configure() method to
> require org.apache.commons.configuration.Configuration as a parameter.
> However, Maven is using an older version of stratum whose Configurable
> interfaces configure() method is still using the Configuration definition
> that was in the old stratum and not the one in commons. So I have kinda run
> into a chicken or the egg paradox trying to build new JCS with the available
> Maven dist and stratum from the CVS.
>
> Will building Maven from the current CVS allow me in turn build the new JCS?
> I know this is REALLY confusing, I apologize.
I've just been using the jars in the repository and it all works for me.
I'll try to update JCS to use commons configuration soon which _should_
clean this up, right?
>
> Thanks,
> Scott
-- jt
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
