Oh, I don't think it is release ready. It will probably take about a month of development. I just wanted to figure out what features would be necessary for a release, present some issues, and get some info on what the process is -- what other projects should it should be integrated with, what sort of testing system we should have, etc.
I'm working on robohelp html documentation for stuff at work. It's very nice. There's lots of stuff to document in JCS. What format should it go in? XML like torque? Do you have some tool for this? Aaron > -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 23, 2002 9:43 PM > To: Turbine Developers List > Subject: Re: JCS features for beta? release > > On 1/23/02 8:58 PM, "Aaron Smuts" <[EMAIL PROTECTED]> wrote: > > > I�d like to discuss what might be involved in making a JCS release. We > > need to decide what feature should be included in a first release (or > > beta release) and where I should focus. > > I think before any release we should probably tackle the build system a > little. I would like to eventually move these components to the commons > but > even in the short term I think individual builds for the components is the > only way we can release individual components. > > We can probably chat about this in NYC. I don't want to hold up a release > of > JCS if you think it's ready and I can help (when I get back from NYC) to > restructure the repository so individual builds and testing will be > possible. I'll also help you get the documentation in XML format, I think > that's necessary before a release. > > As far as what you propose below, until we become more familiar with the > package and if you think it's ready for a release than we can release it. > > > > > > I�m working on a few things: > > 1. Performance � al the bottle necks are in disk IO. I�m running > > jprobe on the tester class. Since the disk gets are synchronous they > > are usually slower than puts. I need to figure out a size to test at. I > > usually test at 20,00 to 50,000 items in a region with only 1000 in > > memory. 1 out of 20 puts is over a ms. 1 out of 6 gets all coming from > > disk is 10-15 ms, the rest ar sub ms. I want to even this out. > > Grouping is slower. > > > > 2. Cleaning up failover > > > > 3. Remote cache clustering. I�m not sure how the cache cluster > > should work. Right now, every cluster is connected to all clustered > > remote server. All puts and removals are replicated. I don�t allow > > cluster gets. Clustered removal and puts are optionally sent to the > > local caches. Group cache cluster may have locking problems. I want to > > change the cluster to use the TCP lateral cache rather than remote. A > > cluster only allows you to scale get requests and provides failover. > > Deciding how cache clustering should work is more difficult than > > implementing it. > > > > 4. Locking. After some thought, I�d like to add a locking > > mechanism. I�m thing about adding a token ring in the remote cache > > cluster. If there is no remote then lock request may return null. The > > remote cache could use the lateral as the token conduit, but the lock > > list. I�m not sure what to do with the lock list. . . . > > > > > > I�d like to continue on the first two and consider clustering and > > locking as coming features. > > > > Aaron > > > > > > -- > > jvz. > > Jason van Zyl > > http://tambora.zenplex.org > http://jakarta.apache.org/turbine > http://jakarta.apache.org/velocity > http://jakarta.apache.org/alexandria > http://jakarta.apache.org/commons > > > > -- > To unsubscribe, e-mail: <mailto:turbine-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:turbine-dev- > [EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
