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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
