tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Cluster maintenance and improvement
Date Thu, 23 Feb 2006 15:51:10 GMT
Hi Filip,

thanks for taking it seriously!

> 1. If we don't primary/secondary will not be available until TC.6
 > 3. Many people are opting out of clustering today because of lack of
 > primary/sec. all-to-all is too inefficient for the general public

I understand your primary motivation. It#s true, primary/secondary would 
be a major improvement. There is one feature that exists now and was not 
available in 2004, that relaxes some of the all-to-all problems. We 
donated enhancements to mod_jk which were taken up by Mladen Turk: the 
domain attribute for a worker. So what is already possible today, is a 
static grouping of cluster nodes into domains. From the tomcat 
perspective that means, you configure multiple disjoint clusters. From 
the mod_jk perspective this means, that you sessions will always be 
routed to a node inside the same tomcat cluster (domain in mod_jk 
notation), and only if all nodes in the domain are in error state, the 
requests are routed to some node who does not have the session. In some 
way it is a very basic static promary/secondary feature and it only 
works in conjunction with mod_jk.

This is very bare bone, but I know several people who build their 4 to 9 
cluster nodes on top of that construction. In fact, susually they had 
their nodes segmented in network terms in smaller groups anyhow, so 
breaking up the cluster into domains fitted their needs well.

Of course, having a dynamic and more transparent primary/secondary 
construction is much more useful. I just want to indicate, why I know 
serveral users, who could work successfully with "all-to-all", 
restricted to domains.

> 2. TC 6 doesn't have a skeleton nor a date yet.
> 5. The instability caused in 5.5.10-5.5.14 could have easily been 
> detected and should have not lasted for four releases. I doubt we should 
> see that again.
 > 6. I'm ready and have the time and commitment to support any changes I
 > make. I am happy to have a 5.5.15-cluster branch for bug fixes
 >   This way when 5.5.16 comes out, the users can choose which one to use.
 > To delay this out of plain "fear of breaking" doesn't seem reasonable to
 > me, if the code base is so messed up that we are too afraid to "touch"
 > it, then it needs to be fixed sooner than later.

I'm very happy about your commitment - really! We really need to push 
the clustering forward and it's fantastic to have you back!

I like your idea of a 5.5.15 maintenance branch. But I'm not sure, if we 
share the same idea, how that will be maintained.

For me it would be OK to freeze the actual cluster code in the 5.5.15 
maintenance branch. The only changes to this branch would be

- bug fixes for important bugs without work-arounds which will only need 
changes in small parts of the code (low complexity)
- security fixes
- bug fixes needed for compatibility with TC core 5.5, e.g. adoption of 
changes to Manager or Session.

So I would like to keep that branch stable, but compatible with 5.5. 
Would that be OK for you?

> 4. Many of the needed features needed for a more complete clustering 
> solution are not possible today due to the tight coupling between 
> components.
> But I would be stretching myself thin trying to maintain two code bases. 
> This maintenance branch is easy to create, just branch the entire 
> cluster module plus, and it is complete.

I agree, so do we have the same idea of the amount of maintenance for 
the maintenance branch? I'm pretty sure, Peter will be happy keeping 
that branch in shape (I think he leaves for holidays now, but he will be 
back next week).

> I have no problem putting this up for a vote, but so far, the only 
> justifications are concerns, when I believe I can offer more features 
> and an easier codebase to maintain.

Voting is good, exchange of arguments as well. I think some of our 
concerns are not just theoretically. Major changes are needed and major 
changes usually break things for some time. So we are just trying to 
find out how to combine the grown user base and the needed improvements. 
I think your idea of a maintenance branch is just right.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message