Sounds like we created a bug in when we altered the queues. I need to
look into it.
Aaron
> -Original Message-
> From: Matthew Cooke [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 18, 2004 2:06 PM
> To: Turbine JCS Users List
> Subject: Remote Cache, issues
>
> I've replaced the vers
This is configurable (see the cache.ccf in src/conf), but that is way
too large as a default. Here are some new disk cache config parameters:
#new disk cache parameter.
jcs.auxiliary.DC.attributes.maxKeySize=1
jcs.auxiliary.DC.attributes.optimizeAtRemoveCount=300
I'm setting the default to 5
New in jcs-1.2-dev:
http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-turbine-jcs/tempbuild/jcs-1.2-dev.jar?rev=1.1
1. The disk cache now has more configuration options
exposed. You can set the purgatory size, recycle bin
size, etc. Also, you can set a bound on the
purgatory. This solves t
I suspect that it was the remove / put problem that I solved in 1.1.2.
It was the only known problem of that sort. It may be due to iteration
but I thought this was resolved. Iteration is very problematic on an
active collection. There is no really good way to do it. We basically
copy the keys
It depends on the configuration. If your unit test
has the log level for JCS set to debug, then it will
be much much slower. If your unit tests is configured
to use a disk cache and the production test is not,
then the times could be affected, but not by that
much. . . . Under all conditions tha
You can configure the cache using a Properties object via the
org.apache.jcs.engine.control.CompositeCacheManager.
Call:
CompositeCacheManager mgr =
CompositeCacheManager.getUnconfiguredInstance()
mgr.configure( properties );
Then use JCS the normal way:
JCS.getInstance( regionName );
Cheers,
I update the site and added docs. Sorry that it took
so long to get Travis to the committers list.
The current dev version is 1.2.2. Remote server
chaining and failover is now functional.
I'll add a FAQ to the docs soon. Suggestions are
welcome.
We also need to acknowledge our contribut
Did you have any errors in the logs?
Did you change the file permissions after the cache
started up? Typically the cache itself creates those
files, so it would have permission. You must have
copied them from somewhere else?
How do you know the objects were still in memory?
What you did, I g
I'm pretty sure that there is no memory leak with the disk cache in
version 1.2.4-dev. I recommend upgrading to this version. The release
is in the tempbuild folder and the repository is tagged.
http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-jcs/tempbuild/
I've been running in pure disk mode
out of the tcp lateral cache. It's
damn fast and seems to recover nicely when a node goes down.
It is very difficult to unit test the remote and lateral auxiliaries
since the cache only works as a singleton. Any suggestions are welcome.
Aaron
> -Original Message-----
> From:
Upgrade to 1.2.4-dev. I'll change the log message if it hasn't been
changed already. Good idea.
Can you send me a more complete stack trace, so I can investigate a bit
further. I wonder if it could be related to the key you are passing in.
. . .
Aaron
> -Original Message-
> From: Ca
I can't think of any other reason why you need the 3.0
version of collections other than the different
packaging.
You can probably put both versions of the collections
jar in the classpath. Since the packaging is
different, it will probably work fine. It wouldn't
take long to test.
Does the ver
l, localOnly = false
> ERROR
>
org.apache.jcs.engine.control.CompositeCache:get(571)-->java.lang.NullPointe
> rException
> DEBUG
>
org.apache.jcs.engine.control.CompositeCache:get(580)-->FeatureHelp
> -
> Miss
> DEBUG
>
org.apache.jcs.engine.control.CompositeCache:get(436)
We have our own LRU in JCS. Maybe it would be best to
switch over to it for all LRU map needs. This would
eliminate the dependency on collections altogether.
Aaron
--- Aaron Smuts <[EMAIL PROTECTED]> wrote:
> I can't think of any other reason why you need the
>
Thanks for all the useful feedback. I'll get to the
specifics soon. We are int he process of moving JCS
up to a site level Jakarta project, so things will be
interrupted for a bit (a week or so). I need to find
out when we are changing repositories before I put in
any patches.
1 and 2 should be
e
>
"jcs.region...elementattributes.IsSpool=true".
> If DC is a disk cache, JCS, could simply assume,
> that specifying a disk
> cache
> for the reason might have the reason that it should
> be used. :-)
>
> So probably it would make sense to remove the three
> attrib
Hi Daniel.
A removeAll sends one message, not a message for each
item.
Jgroups is fine, but it is slower than the otehr
options.
I'd use tcp lateral connections or the remote rmi
server.
If you use the tcp lateral, then you need to specify
the servers a cache should connect to. If you have
only one console. Does anyone have
> any experience
> with this, and know of a way to specify a different
> value for
> each node in a cluster?
>
You can definitely set different values for different
servers.
Either way, I think the remote cache is a better
option. It solves your configur
you. There is only
> one place to
> configure all the servers. I am not sure if there
> is a way to
> specify a different value for each server, and you
> would
> actually have only one console. Does anyone have
> any experience
> with this, and know of a way to speci
--- Daniel Rosenbaum <[EMAIL PROTECTED]>
wrote:
> So if I understand correctly, there is a possibility
> of serving
> raw data on server B if the invalidate event on
> server A is
> stuck in the queue. Is this correct?
Stuck in the queue is not the problem. There is a
period of time that B h
--- Daniel Rosenbaum <[EMAIL PROTECTED]>
wrote:
> I have a side concern specific to using Hibernate
> with
> distributed caching, particularly when caching
> collections. I
> can best describe my concern with a (somewhat
> contrived)
> example.
Personally, I wouldn't cache inside Hibernate. I'
> True, but part of the reason to use a cache is for
> speed. It is
> expensive to always have to reload a collection of
> 600-1000
> rows, so it is a perfect candidate for caching, but
> that is not
> acceptable if it is at the cost of having invalid
> data.
>
That depends. Some data is ok st
your
distribution settings and your environment, this might not be a complete
list of all the elements that are in the region in all the jvms.
Let me know what you are trying to do. I may have a better idea.
Aaron
Aaron Smuts
Director, Systems and Development
e-Business Division
he cache region.
>
> I don't want to expire the objects as that will require user requests to
> re-query the database which be lengthy for some items.
>
>
> very long...sorry
>
> scott
>
>
>
>
> > -Original Message-
> > From: Aaron Smu
would be
> great -- a RefreshingCacheAccess that implements the additional refresh
> capability.
>
> On Mon, 2002-04-29 at 18:16, Aaron Smuts wrote:
> > You have a very tricky situation on your hands.
> >
> > Is there anyway that you can get in between the legacy app that upda
You have to think about how this refreshable object will behave when passed
to another machine or serialized to disk. You don't want to serialize all
your utilities.
It might be easier to add a listener by name to the element attributes. In
the cache hub when an element is expired on request, o
o maybe that's
> why
> I missed the logic.
>
> Scott
>
>
> > -Original Message-
> > From: James Taylor [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, April 30, 2002 11:08 AM
> > To: Turbine JCS Users List
> > Subject: RE: How do you retrieve a
: Tuesday, April 30, 2002 11:08 AM
> To: Turbine JCS Users List
> Subject: RE: How do you retrieve a collection keys for a cache region
>
> On Tue, 2002-04-30 at 10:12, Aaron Smuts wrote:
> > You have to think about how this refreshable object will behave when
> passed
> >
, April 30, 2002 11:08 AM
> To: Turbine JCS Users List
> Subject: RE: How do you retrieve a collection keys for a cache region
>
> On Tue, 2002-04-30 at 10:12, Aaron Smuts wrote:
> > You have to think about how this refreshable object will behave when
> passed
> > to another
The put will only be announced if the log level is set to debug.
Is the cache region configured for lateral distribution?
Were you able to get the item from the other JVM?
Aaron
> -Original Message-
> From: Sam [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 07, 2002 3:07 AM
> T
could go as far as creating IBackgroundEvent and IForegroundEvent
> interfaces
> to make prioritizing events easier and more component oriented.
Yes this could be done and probably should be.
>
>
> my $0.02,
> Scott
>
>
> > -Original Message-
> > Fr
Hmmn. Any ideas on why this might be happening. I'll look into it.
> -Original Message-
> From: James Taylor [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 09, 2002 3:41 PM
> To: Turbine JCS Users List
> Subject: RE: cache event listeners, like jcache
>
>
> > Just tell the memory ca
Please send the cache.ccf that you are using.
You probably need to put in the default configuration lines.
There is some documentation on the JCS web site that may help.
Aaron
> -Original Message-
> From: xMySign for JCS [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 28, 2002 9:12 AM
It might be nice to be able to run multiple instances of the cache, but that
is completely unnecessary to solve this simple problem.
You don't need multiple instances of the JCS caching system, you just need
to use different regions. The entire system is built around the idea of
separate cache
nfig file) and let these runtime defined regions
> have the same settings as this predefined region?
>
> Thanks,
> Maarten
>
> On Thu, 6 Jun 2002, Aaron Smuts wrote:
>
> > It might be nice to be able to run multiple instances of the cache, but
> that
> > is co
> > > How can I define these unique regions at runtime (since I don't know
> which
> > > webservices will be called in advance because the user can add such
> > > servers at execution time).
> > >
> > > And if I define these regions at
You just need to name your keys more descriptively. Add part, or all, of
the webservice name in the key, then a colon, and then the key and you
should be fine.
get( webservice_name + ":" + id );
Let's do an experiment. Think of the cache as a hashtable. Say the
elements never need to expi
> You can create a new region at any time, and it will be setup with
> whatever defaults have been configured.
>
Or you can just name your keys in a hierarchy, using the user id as part of
each key.
> JCS would certainly be able to do it to, but one IMPORTANT fact is that
> there is no eas
A quick thought.
I was working with the Javagroups folks when I made the auxiliary. They
were making some changes that would improve performance and callbacks for
JCS. I never implemented the new methods. I'll go through their email
archive to see.
Aaron
> -Original Message-
> From:
When I restart it,
> does
> it reload the entries and distributes them to the caches registered in
the
> lateral
> region of the config file?
Does what distribute them? Each instance of JCS, has cache regions that
can be configured to use lateral cache auxiliaries.
On startup, the lateral cac
ecently
> sized memory cache, the disk cache is auxiliary. I guess your solution
> wouldn't help then.
> Michal
>
>
>
> > -Ursprungliche Nachricht-
> > Von: Aaron Smuts [mailto:[EMAIL PROTECTED]
> > Gesendet: Mittwoch, 4. Juni 2003 16:37
> > An:
> -Original Message-
> From: Vossberg, Michal [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2003 5:28 AM
> To: 'Turbine JCS Users List'
> Subject: AW: Spooling after each update
>
> Guys,
>
> thanks for the insight. Aaron's suggestion works well, although now I
feel
> I
> have some
JCS is not entirely JCache compliant. There were licensing issues and
the specification is not set in stone, so JCS was built how we saw best.
It does not implement object ownership. I discuss other differences on
the web site.
http://jakarta.apache.org/turbine/jcs/JCSandJCACHE.html
(Just a
I assume the problem Hanson encountered is something like this: A
program was using an object retrieved from the cache. Another instance
of same program or another program modified the object at the same time.
This probably caused some bugs that were very difficult to duplicate and
track down.
I'm ignoring the problem with the groups for the moment. Try your test
without using the groups at all.
What was your test code like for JPROBE? The indexed disk cache keeps
the key and the location of the item in the file in memory. This is
kept in the disk element descriptor, which is very
You could just set the memory size to some very small number like 1.
This way everything will go right to disk.
> -Original Message-
> From: Vossberg, Michal [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 04, 2003 6:49 AM
> To: '[EMAIL PROTECTED]'
> Subject: Spooling after each updat
ch update
>
> Aaron,
> thanks, but maybe I didn't make myself clear: I still want to use a
> decently
> sized memory cache, the disk cache is auxiliary. I guess your solution
> wouldn't help then.
> Michal
>
>
>
> > -Ursprungliche Nachricht--
You will need to have a policy file granting access to the rmi server.
> -Original Message-
> From: Neil Avery [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 20, 2003 11:33 AM
> To: turbine-jcs-user
> Subject: Is Remote Cache working?
>
>
>
>
>
> Hi All,
> Ive been digging around the
The cache.ccf can be in any directory. It just needs to be in the
classpath. That's pretty standard.
Aaron
> -Original Message-
> From: Honig, Daniel [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 24, 2003 11:29 AM
> To: '[EMAIL PROTECTED]'
> Subject: Changing the default configurati
ired.
>
> It seems an easy change to make but I just hate branching away
> from the code in CVS for this.
>
> -d.
>
>
>
>
> -Original Message-
> From: Aaron Smuts [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 24, 2003 12:39 PM
> To: 'Tur
Gotcha. Could you just create a properties object and pass it to this
method?
configure
public void configure(java.util.Properties props)Configure from
properties object
Parameters:
props -
-
To unsubscribe, e-mail: [EMAIL
Right now you can only use hierarchical delete if you know the beginning
of the key. The idea was that it would be too slow to look for a
partial match. Perhaps it would be fine. The idea was that groups
would solve tis other problem. You would put everything in a page group
and then delete eve
Try setting usememoryshrinker to false and see if you get the same
problem.
Aaron
> -Original Message-
> From: Daniel Rosenbaum [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 11, 2003 9:39 AM
> To: Turbine JCS Users List
> Subject: RE: Memory test
>
> As a follow up, I let my test
If turning off the memory shrinker doesn't work, try not using a disk
cache at all.
I want to isolate the issue.
Aaron
> -Original Message-
> From: Daniel Rosenbaum [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 11, 2003 9:39 AM
> To: Turbine JCS Users List
> Subject: RE: Memory
There cache isn't made to just dump items into it as fast as possible.
Hmmn
Aaron
> -Original Message-
> From: Daniel Rosenbaum [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 15, 2003 4:33 PM
> To: Turbine JCS Users List
> Subject: Re: out of memory error with TestDiskCache
>
> Sh
Some notes on thread usage in JCS:
All puts to lateral caches are done in background threads. The indexed
disk cache uses a two stage process, putting elements in a purgatory
before disk storage. Recovery of auxiliary caches occurs in background
threads. Auxiliaries are wrapped in balking metho
s?
Operations
> with
> the aux disk cache, etc?
>
> -----Original Message-
> From: Aaron Smuts [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 10, 2003 4:14 PM
> To: 'Turbine JCS Users List'
> Subject: RE: general question on JCS
>
>
> Some note
Ya. You shouldn't need to do any synchronization around JCS calls in
most conceivable cases.
Remember that the cache passes objects by reference. If you change an
object you get from the cache, the object in the cache is changed.
Aaron
> -Original Message-
> From: Craig Johannse
That doesn't sound right. Those threads are trying to perform some
event to an auxiliary cache. Is everything working? Does the disk
cache have write access to the file? Do you have laterals that might be
blocked by a firewall?
Aaron
> -Original Message-
> From: Nicholas J. Dellamag
Paste your config file in an email.
> -Original Message-
> From: Nicholas J. Dellamaggiore [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 29, 2003 10:01 PM
> To: [EMAIL PROTECTED]
> Subject: Fwd: RE: ElementEventQueue question
>
> The thread problem is actually pretty bad. We left
I'm surprised that it works with all those periods in the name of your
region. I'm not sure this will parse correctly. Remove the periods.
Replace them with _ and test.
You have the memory shrinker on but have not defined a maxlife seconds.
I think the default in this case is to treat the elemen
I once had an management mbean running in an embedded sever in each
cache. It allowed for listing of cache regions and provided the ability
to clear any or all regions. It was very useful for emergency
consistency control.
Aaron
> -Original Message-
> From: paulo caroli [mailto:[EMAIL P
ry very shortly in order to flush groups within a region.
>
> ToddC
>
>
> -Original Message-
> From: Aaron Smuts [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 05, 2003 11:06 AM
> To: 'Turbine JCS Users List'
> Subject: RE: jmx
>
>
> I once had an m
You just need to local caches running. If you are running an example in
Tomcat, start another on a different port and configure a region in each
cache.ccf file to use a lateral cache. Each will need to listen on a
different port. . .
> -Original Message-
> From: paulo caroli [mailto:[EM
would provide in open source? Or if you
are
> willing, just to provide to the email list without 'open source'
strings
> attached. Regardless, sucy a management tool is something we will
build
> very very shortly in order to flush groups within a region.
>
> ToddC
>
A proper shutdown is required. While running, the indexeddiskcache
store the keys in memory. This is why it is far faster than any other
disk system. The keys are so small it does not take up much memory.
This is when defragmentation occurs also. I was working on on-the-fly
defragmentation, bu
There must be a bug in save. I'll take a look. If there was a patch,
please send it to me.
Aaron
> -Original Message-
> From: Jim Arnott [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 13, 2003 10:20 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [indexeddiskcache] key file not writte
Can you send the code to this net.sf.hibernate.cache.QueryKey class?
> -Original Message-
> From: Ryan Breidenbach [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 13, 2003 11:51 AM
> To: [EMAIL PROTECTED]
> Subject: CacheElement hashCode problem
>
> I am using JCS with Hibernate fo
Can you send me a stack trace also.
> -Original Message-
> From: Ryan Breidenbach [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 13, 2003 11:51 AM
> To: [EMAIL PROTECTED]
> Subject: CacheElement hashCode problem
>
> I am using JCS with Hibernate for caching, and I came across a
prob
}
> });
> }
>
>
> Here is where the QueryKey class is breaking:
>
> public boolean equals(Object other) {
> QueryKey that = (QueryKey) other;
> ...
>
> This object passed in is a CacheElement. Where is is cast to
tCacheable(true);
> return query.list();
> }
> });
> }
>
>
> Here is where the QueryKey class is breaking:
>
> public boolean equals(Object other) {
> QueryKey that = (QueryKey) other;
> ...
>
> Th
I started implementing event handlers, but it may not be finished yet.
> -Original Message-
> From: Todd Carmichael [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 17, 2003 11:14 AM
> To: 'Turbine JCS Users List'
> Subject: RE: Alter behavior through event handling?
>
> +1 for event ha
In the cache access class you can get the elementattributes for and
item. Every item in the cache is given one by default. If you are
putting something in, you can get the default elementattributes and then
modify it and then use the put method that takes the elementattributes
as an argument.
The extra thread mystery is solved. The elementeventqueue is only
lightly used. I made it so that only one such thread should be created
for all regions. Later we can make it one per region as needed, if
this is necessary.
This should solve the thread mystery.
Aaron
> -Original Message--
Remote failover is not fully implemented, although the remote server
works great as a distribution plugin.
When you run JCS you create regions. A region is a place where elements
are stored. You can have multiple regions. Each region can be given
different default behaviors. Each element in a
The MRU memory manager is a sample of how to build another memory plugin
if you so desired. The LRU should be used, the one configured in all
the sample configuration files.
Aaron
> -Original Message-
> From: Snehal Khanna [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 04, 2003 12:
ed in MRUMemoryCache
>
> Thanks Aaron. A follow up question. MRUMemoryCache
> uses a LinkedList whereas LRUMemoryCache implements
> its own linked list using MemoryElementDescritor
> types.
>
> Any reason why LRU manager does not use LinkedList?
>
> Thanks
> Sne
I'm not sure what the problem is exactly, but I don't recommend using
large objects as keys. If you want to take advantage of the fastest way
to spool data on disk, then you would use the indexeddiskcache
auxiliary. This puts the least recently used data on disk and keeps the
keys in memory. Als
I suppose this is for emergency use. One way is to build a simple page
that lists all the regions and has a link where you can call removeall.
There should be an example in the experimental codebase. Other options
depend on your remote configuration.
Aaron
> -Original Message-
> From:
You are creating a new ElementAtrributes object, which probably defaults
to isEternal=true. If that is the case, it may never expire.
Try getting the default for the region and then modifying it. Something
like this should work:
JCS cache = getCacheForRegion(regionName);
ElementAttrib
The diskcache keys are kept in memory until the cache is properly
shutdown.
You must have two vm's running, perhaps 2 instances of the portal server
running, or a test program running?
Aaron
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, Janu
I can't think of a clean way to do it. The disk cache is treated pretty
much as one of the other auxiliary caches. Nothing like this was built
into the interfaces for any of the remote auxiliaries, since for them it
wouldn't be very useful.
Another reason why this doesn't exist for disk caches
The list generation fails fast. Instead of giving you the live list of
keys, on which you will get a change in underlying map error, the cache
gives you a copy. But the copy process also fails fast. Instead of
locking the underlying map, I allow the copy to fail if the underlying
map changes. It
If you can come up with a better solution to how to iterate through an
active map, let me know. I did my best.
Aaron
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Sunday, January 18, 2004 11:48 PM
> To: Turbine JCS Users List
> Subject: RE: Access to Al
No, no one has ever asked if JCS is slow. Something is definitely
wrong. The cache is not significantly slower than a hashtable. Can you
give more details about your configuration (i.e. the cache.ccf file) and
what you are caching.
> -Original Message-
> From: Spaggiari, Jean-Marc [ma
(mot);
> else
> enCache.addElement (mot);
> }
> System.out.println (new Date ());
> }
> catch (Exception e)
> {
> e.printStackTrace();
> }
>
>
> Writing in cache :
>
>
>
You need to call "maven rmic" (I think) to create the stubs.
> -Original Message-
> From: bob steadman [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 21, 2004 10:54 AM
> To: [EMAIL PROTECTED]
> Subject: setting up Remote Caching Service
>
> I'm attempting to set up RCS and I'm run
After that, build using the standard maven command to get the stubs in
the jar.
> -Original Message-
> From: bob steadman [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 21, 2004 10:54 AM
> To: [EMAIL PROTECTED]
> Subject: setting up Remote Caching Service
>
> I'm attempting to set u
-jcs-src directory if ran
%MAVEN_HOME/bin/maven
> and
> it build out the target directory. Is there another step that I may
be
> missing.
>
> Thanks for your help.
>
>
> - Original Message -
> From: "Aaron Smuts" <[EMAIL PROTECTED]>
> To
The RemoteCache will do what you want, since it was not designed as just
a broadcaster. The local caches hook up to the remote cache, send it
update, the remote cache broadcasts delete requests for that item to the
other locals, and then if one of them needs an item and it is not stored
locally th
This sounds very strange. Are you sure the cache was returning the
wrong value? There is no way your program could have a multithreading
problem and switch up some entries? The cache passes objects by
reference--could you have tried to recycled some entry somewhere?
Aaron
> -Original Messa
I'm not sure why all this complexity is necessary. Can't you use
something more efficient, like a simple _ delimited string for the key?
The cache has built in hierarchical removal for keys in this form . . .
How the items are retrieved is not exposed to the user of JCS. There is
no interface th
There is a known bug. No big deal, but I need to put in the simple fix.
Aaron
> -Original Message-
> From: Unico Hommes [mailto:[EMAIL PROTECTED]
> Sent: Saturday, March 06, 2004 9:42 AM
> To: [EMAIL PROTECTED]
> Subject: Proper shutdown for auxiliary?
>
>
> Hi guys,
>
> As you may k
JCS could use more contributors. I'm clearly a bit overextended and
haven't had much time to work on the project recently. This should
change soon. I apologize for any inconveniences this is causing.
The nice thing about JCS is that is it completely plugable. If you have
a new memory cache imp
If there are significant changes, one way to go it to add the changed
auxiliaries as new implementations. Then, the old ones can be
depreciated or eventually removed. For simple bug fixes, this is
clearly not necessary.
Changing something like the event queue is a different matter.
I'm for ha
If we add an active committer to the current project, add in new
auxiliaries, and fix any bugs, then we would be ready for a supportable
release and JCS would be a very good candidate for moving up a level. I
don't know what's involved in making JCS a Jakarta subproject, but I
can't imagine that t
I only meant if they were significantly different. I do tend to be a
pack rat though. Ha! The idea was for there to be a variety of good
options . . .
Let's get Travis commit privileges and move on.
+1
Aaron
> -Original Message-
> From: Travis Savo [mailto:[EMAIL PROTECTED]
> Sent: M
at
> did not help much.
>
> Can I see a patch that only involves the relevant changes being
> proposed?
>
> john mcnally
>
> On Mon, 2004-04-05 at 16:23, James Taylor wrote:
> > On Apr 5, 2004, at 3:57 PM, Aaron Smuts wrote:
> > &
asmuts 2004/04/13 23:24:18
Modified:src/java/org/apache/jcs/auxiliary/disk/indexed
IndexedDiskCache.java IndexedDisk.java
src/java/org/apache/jcs/auxiliary/disk
AbstractDiskCache.java
Log:
Fixed diskcache key storage shu
Hi Travis,
Can you send me your updates to the remote cache, indicating what's
changed.
It's very hard to tell what you've done just by going through the code.
I'm afraid that I will miss a change and spend hours hunting down
differences.
Thanks,
Aaron
> -Original Message-
> From: Tr
1 - 100 of 158 matches
Mail list logo
