jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Cooke <mpcoo...@lineone.net>
Subject Re: Project status
Date Thu, 01 Apr 2004 11:04:44 GMT
I am currently in the process of rolling out a JCS caching solution to a fairly high 
load production cluster of 16 servers.

A few points I have discovered during development/testing:

* JCS works standandalone, even though it appears to be in turbine.

* The Disk cache can not currently be used as a persistance mechanism, it is really 
just an overflow for the LRU memory cache - this is non-obvious from the 
documentation (the docs ignore a bug in the diskcache index thingy which prevents it 
from working). The disk cache problem is damn annoying and someone keeps submitting a 
fix that isn't put in.

* The LateralTCP distribution model is not as transparent as you would expect, 
machines have to explicitly connect to other machines rather than using multicast. I 
haven't tried the javagroups solution as it was marked as experimental.

* There is no way to force a complete re-sync of a cache when a machine is rebooted, 
although it can actively fetch content from another server using the TCPLateral 
mechanism.

* The list of IP addresses in TCPlateral are not iterated over in an attempt to 
obtain content these are only used if a machine is currently unavailable. This means 
setting up a ring based distribution mechanism is quite complicated and guaranteeing 
items in one cache show up in another is also complicated.

When JCS is set up and working in our test enviroment it works very well. You get a 
lot of functionality without having to write much code, though you may have to spend 
quite a lot of time modifying non obvious config files on different machines.

I've written a small suite of JUnit tests which test quite a lot of non-distributed 
JCS behaviour and JCS does behave correctly. (The only exception is the max size 
which can fluctuate by 1 item due to the shrinking code removing items in blocks of 2 
- but this probably won't affect most people)

I've had some problems with wrong objects being served in our system when we enabled 
JCS, but as far as I can tell this is not a problem in JCS. I'll be trying it again 
this week with simple strings as keys rather than objects I am trying to use JCS to 
replace our existing caching system which is based on a memory cache, persisted 
Objects as XML files and RSync (this is a bit ick and rsync is flakey).

Regards,
Matt.


Guillaume Nodet wrote:

> I'm considering using JCS in our projects has the cache layer.
> However, i'd like to know what is the status of this project.
> 
> The points are:
> 	1°/ Is this project still maintained ?
> 	2°/ Why does'nt it is considered as a real project in the apache foundation
> 	    (and accessed maybe in db, has releases for its own) ?
> 	3°/ I saw there has been a fork to create EHCache
> (http://ehcache.sourceforge.net/)
>           and that they state there were problems in threading and memory
> leaks. Can i
> 	    have some comments on that ?
> 	4°/ i saw in CVS that there is no more activity since a long time. Has the
> project
> 	    reached its final status ?
> 
> There are other open source projects for distributed cache systems, but the
> great feature i like about JCS is the remote cache and the ability to
> connect
> the remote cache to another remote cache aso... leading to very effective
> use of network bandwidth when using this in a network with a star topology.
> 
> Sincerely,
> 
> Guillaume Nodet
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org
> 
> 


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


Mime
View raw message