jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Eade <se...@backstagetech.com.au>
Subject Re: JCS fixes/branch
Date Thu, 01 Apr 2004 23:53:30 GMT

This sounds great.  The discussions in the last 24 hours indicate that 
there is interest in reviving JCS - especially if the problems you are 
working on are addressed.  When you get a little further along the path 
I will be happy to apply your patches to the JCS cvs (assuming there are 
no licensing issues - I am checking about this).

 From the sounds of things you might be interested in becoming a JCS 
committer.  There are procedures to follow in order to do this, but 
posting patches and having them accepted is the starting point.

I will also look back and see if I can dig up where people were 
suggesting JCS be moved to, on the jakarta-general mailing list they 
discussed JCS becoming wither part of jakarta-commons or moving it to a 
direct jakarta sub-project, and see if I can perhaps get the ball rolling.


Scott Eade
Backstage Technologies Pty. Ltd.

Travis Savo wrote:

>Looks like my first aptempt didn't make it to the list, so I'll post again.
>Sorry if this is repetative....
>Hi, my name's Travis Savo. I've been a JCS user/developer for about 6 months
>I originally started using it because the project I was working on was using
>Hibernate, which used JCS as it's caching mechanism.
>I found it to be a wonderful product on the surface, but when I tried to use
>some of it's more advanced features, namely RemoteCache, I ran into barrier
>after barrier.
>Yes, there is a memory leak in the memory store. The linked list can become
>a different size than the hash map.
>Yes, there's deadlocks in the IndexedDiskCache.
>There's bugs in removing things from Remote Cache too, and other little
>pesky bugs that pop up only on rare occasions when used it new and exciting
>So I patched up the bugs in remote cache, changed the use of threads to be
>MUCH more conservative in remote cache (Try running a remote cache with 1000
>regions and watch the threads spawn in the original!), removed all the
>instances of double-checked locking, ripped out the IndexedDiskCache and
>replaced it with EHCache's disk store, ripped out the LRUMemoryCache and
>replaced it with EHCache's MemoryStore, added some better stastics
>collection which can be completely disabled for 'lean and mean mode', and
>was in the process of fixing up the Javadoc, writing some documentation on
>how to properly make use of RemoteCache and LateralCache (and when to use
>them) and preparing to present it to the world when I saw that there were
>other people out there who were having the same problems as me.
>The thing I noticed was EHCache's code was much cleaner, has unit tests for
>it, and was doing exactly the same thing in essence that JCS was trying to
>do (LRU memory store, indexed disk cache). Porting them over was
>surprisingly simple, and the result was that the memory leaks and deadlocks
>have disappeared, but the original functionality AND INTERFACES remains
>So while I prepare the result of my efforts for public presentation, I
>invite you to email me, and I will send you a zip of the source code so you
>can compare and critique my efforts. My goal was to get it working, stable,
>and useable in a production environment, without changing any of the public
>interfaces, and in fact only changing what was broken, which I believe I
>have accomplished.
>My email address is tsavo@ifilm.com. The zip is a little over 2 meg,
>includes all dependencies, and is a drop-in replacement for anything using
>JCS (minus the above mentioned bugs).
>I do indent to start hosting this public ally once I've completed the
>documentation, but if you want it now just let me know.
>Hope this is of some assistance to someone!
>-Travis Savo <tsavo@ifilm.com>

To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org

View raw message