jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Smuts <aasm...@wisc.edu>
Subject RE: Additional problems.
Date Tue, 27 Apr 2004 13:35:50 GMT

> -----Original Message-----
> From: Matthew Cooke [mailto:mpcooke3@lineone.net]
> Sent: Tuesday, April 27, 2004 6:38 AM
> To: turbine-jcs-user@jakarta.apache.org
> 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
> 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
> 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
> 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
> 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
> 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

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.  



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