> From: Remy Maucherat > Subject: Re: New clustered session manager available > Date: Wed, 08 Sep 2004 23:53:49 -0700 > ------------------------------------------------------------------------ > > Rob Block wrote: > > > Tomcat developers, > > > I have created a plugin for Tomcat 5 that provides scalable > session > clustering by replicating each session to a single node rather > than > the whole cluster. The plugin uses the jcluster > (http://jcluster.dev.java.net) API for communication, > membership and > failover, a BSD-licensed set of API's that is similar to > jgroups and > has a working implementation that uses jgroups as the impl. (I > worked with Bela Ban and others on the jcluster API spec after > he and > Filip Hanik told me about Tomcat not being able to use jgroups > because of the LGPL license.) > > The tomcat plugin itself is hosted at > https://sourceforge.net/projects/tomcat-jg - the same place Filip > developed the full-replication jgroups-based session manager that > is > now integrated into Tomcat 5. The initial (alpha quality) release > of > the plugin is available to users and developers as of today; > hopefully in the future it can be integrated into the Tomcat > source. > > > To download the plugin: go to tomcat-jg site (above) and select > tomcat-jcluster package under File Releases. It contains three jar > files, plus release notes for setting it up: > > > catalina-ha.jar - the tomcat plugin jcluster.jar - jcluster API > jcluster-plugin.jar - jgroups impl of jcluster > > There are only two source files in the plugin itself (since they > extend and make use of existing Tomcat 5 classes). They can be > viewed online at: > > > http://cvs.sourceforge.net/viewcvs.py/tomcat-jg/tomcat-javagroups/src/org/apache/catalina/cluster/session/ > > > The jcluster javadoc can be browsed online at > https://jcluster.dev.java.net/nonav/javadoc/index.html. > > > It is mostly a set of interfaces that roughly map to jgroups > classes > like JChannel, PullPushAdapter and RpcDispatcher. (The one > exception > is the net.jcluster.ha package, which allows state replication and > failover for objects and services using configurable policies for > backup selection and failover. It does not have a counterpart in > jgroups and is the basis for much of the plugin implementation.) > > > I would appreciate feedback from the Tomcat community about the > jcluster API itself, as well as the feasibility of using it as the > clustering framework for Tomcat down the road. It would actually > be > very straightforward to write a jcluster implementation that calls > the existing Tomcat clustering classes (ClusterSender/Receiver, > McastService, etc.), so that plugging in jgroups would be an > optional > step. > > I realize this is a lot of information for those of you who did > not know about any of this ongoing work, but I'll be happy to > answer any questions you have about jcluster, the plugin, who I am, > why I'm doing this and why you should care. > ------------------------------------------------------------------------ > > Since we have something working quite well thanks to Filip (and it > almost does farming), I think we're going to keep it.
I certainly wasn't suggesting you would toss it out, I'm sure it's fully functional and stable. However, the current design does have inherent scalability limitations, since memory usage would explode in a cluster of more than a few nodes. That's okay for many users who use two-node clusters for basic HA. But in a larger environment with many nodes running the same app, one is required (or at least strongly advised for resource reasons) to partition the network into groups of two-node clusters, and also route the various load balancers appropriately. This can be done (and I'm sure is done all the time), but requires considerable admin. overhead that the proposed solution is designed to alleviate if not completely eliminate. Btw, what do you mean by "farming" in this context? Are we talking about the same thing (replication to limited set of nodes)? I know this was planned for a future release, is it close to being done? > You can of course use the cluster API of Tomcat if you wish to > provide a seamless integration to your users. Well, kind of. The core layer of jcluster (messaging and membership) map easily to tomcat's interfaces (CatalinaCluster, etc.) and impl. But jcluster has higher level services for doing group rpc and object replication/failover, which tomcat does not, so porting my plugin to use tomcat's clustering primitives, I'd have to add most of the higher layer stuff anyway. > I don't wish to add new dependencies because of incremental > improvements, and I don't see a need either for supporting every > cluster replication framework out of the box either (each framework > can ship a Tomcat plugin with its distribution, I think), Wouldn't expect you too. But it was my understanding (and correct me if I'm wrong) from discusions with Bela, Fillip and a few others, that some time ago you guys were considering using jgroups for Tomcat's cluster framework but decided not to because of the LGPL license. The reason for doing jcluster was largely to create a jgroups-compatible API with a BSD license so that jgroups and possibly other impls could be plugged in seamlessly underneath. > esp since our various loadbalancers are not adapted to the kind of > replication you propose yet. My plugin will work well with any load balancer that sticks (session- or client-wise) to a target host. It need not know anything about a session's backup location. That is because after a failover, the plugin automatically migrates sessions from the backup node to the redirect node. I have tested this on a 3-node cluster using pen as the load balancer/front end. Works great. Anyway, at least consider it. Maybe one of you can check out the code at some point. Even if you don't decide to adopt it as a whole, there may be some ideas that would work well with your existing impl. If you don't mind (the rules about cross-posting notwithstanding), I'm going to announce the plugin to the tomcat-user list, since some folks there might be interested. Also, if you reply, please CC me since I only subscribe to the digest. Regards, Rob > Rémy > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
