> -----Original Message----- > From: Matthew Cooke [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 27, 2004 6:38 AM > To: [EMAIL PROTECTED] > Subject: Re: Additional problems.
on the website and is definitely broken. Under > high load you start to receive values back for the *previously* > requested key. No one has ever reported anything similar and you had made significant changes to the basic comparison of keys. I didn't think that we determined if there was actually a bug. > I therefore couldn't use the 'supported' version as it was broken and I > didn't have time to look into it. > > The Apache Jakarta project is quite well known for their quality > projects but the release version of JCS (at least 3 weeks ago) was very > buggy, and it's not just my experience with the LTCP auxiliary judging > by this mailing list. There has not been a release of JCS. I'm trying to fix any remaining bugs before issuing a beta release, but there has been no release. > So regardless of whether the fixes from Travis were applied to the CVS > version I think that the website should be updated to indicate that the > released version of JCS is not stable or at a bare minimum the LTCP > cache is not stable. > > You get the impression from the website that this is a stable project > and would assume that their are at least no show stopping bugs such as > getting wrong values for a key. I don't think that bug exists, but I'd like to find it if it did. It's not fair that new people using JCS > are download JCS and only after using it in a production enviroment > discover the bugs. Then like me, they will possibly sign up to the > mailing to list and find that it's already known that lot's of other > people are having problems with JCS. Probably also like me they will get > a great sinking feeling and start applying random patches that show up > on the JCS mailing list in a desperate attempt to keep things working. > What makes a patch random and another not? > It's this situation that forced me into using some branched version of > JCS in the first place - I certainly didn't want to integrate some > non-standard version of JCS. > > Please don't take all this as a rant as I am being serious. At least > until most of the critical bugs are worked out, I think the website > should be updated to reflect the unstable nature of the code. > > --- > On a separate note: > I would like to know if Travis's changes are going to be applied and if > not, is there a working distribution mechanism in CVS now? > If Travis's code needs unit tests and this is holding things back, I > could help out. What are Travis's changes exactly. I haven't received a single diff. I applied several fixes that other pointed out and other had noticed (fixed the remove from expiration, for one), I added an experimental memorycache on Travis's model (but it required jdk 1.4), I added the only fix to the LTCP Travis made which was to a method that only gets used if you run the LTCP in get mode, and I added an experimental element event handler. There is only one change that I know of that I haven't got in, and that's changing the local identifier to along, which won't do you any good. If there is anything else, I don't know about it. If you want to help, try and replicate that LTCP bug without modifying the equals method (or whatever you changed), if it happens try to explain how it might be possible, and then we can go from there. Or some test that would show me the bug was in JCS would be nice. Also, I'd like to know more about the memory problem you were having. I'm not sure if I got answers to my questions about where it was occurring and if anything could be keeping references to the elements. Cheers, Aaron --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
