tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Rossbach>
Subject Re: Cluster maintenance and improvement
Date Thu, 23 Feb 2006 17:28:19 GMT

Am 23.02.2006 um 16:51 schrieb Rainer Jung:

> 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.
My greatest cluster have 5 domains with 20 tomcat instance up and  
runnnig, but we must change
the mod_jk code a little bit. The site has a lot of traffic and is  
very stable.

> 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.
I also :-)
>> 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!
Yes, it was very nice that you have time and back on board. I like to  
work together an build another tomcat cluster innovation. But we must  
very careful with the existing users.

> 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).
Yes, and now I start....
>> 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.
I think to create a new cluster2 module is the right way.

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

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

View raw message