tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: Cluster maintenance and improvement
Date Thu, 23 Feb 2006 15:13:55 GMT
Rainer, all are very good thoughts. Here is why I opt we still move forward

1. If we don't primary/secondary will not be available until TC.6
2. TC 6 doesn't have a skeleton nor a date yet.
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
4. Many of the needed features needed for a more complete clustering 
solution are not possible today due to the tight coupling between 
components.
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. 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 ClusterRuleSet.java, and it is complete.

The main reason being that I don't think I would want to wait for TC6 to 
provide primary/secondary replication. I also don't think that users 
wanting more features should suffer because of previous lack of testing.

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 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.

Filip

Rainer Jung wrote:
> Hi Filip, hi all developers,
>
> I think TC clustering from a users perspective got more robust in the 
> last two years. Whe we started playing around with it in 2004 it was 
> great, that we all basic functionality already worked, but you might 
> remember, that I contributed a couple of fixes to make DeltaManager 
> finally work in around 5.0.27.
>
> When we started to check robustness for mission-critical production I 
> found some limitations, that made clustering (in our use case) a 
> little fragile, and I'm thankful to Peter, that he included the 
> fastasync replication mode.
>
> During early stages of 5.5 the amount of changes to cluster introduced 
> some instability and finally broke it (the compression change), but 
> the bugs were resolved very quickly after user feedback. At the end 
> everyone was confident, that TC cluster was stable again starting from 
> 5.5.15.
>
> At the moment TC 5.5 core is in maintenance mode. Commiters for core 
> Tomcat usually only apply bug changes to 5.5, no major changes were 
> applied to the core parts. So the release schedule for 5.5 is mainly 
> correlated to bug fixes.
>
> Major Changes to TC cluster might result in a conflict between TC 
> releases (bug driven) and Cluster releases (refactoring driven), at 
> least as long as TC core and the cluster module are released together.
>
> So I would also very much appreciate a conservative refactoring and 
> enhancement strategy for 5.5 cluster. Major changes (better: risk) 
> should be directly done in TC 6 (which is not that far away).
>
> I agree, taht there is a lot of code refactoring necessary for the 
> cluster as a basis for adding more and important functionality.
>
> But in the last two years the amount of people doing real production 
> with TC cluster increased a lot. I think it would really help to have 
> a conservatively maintained branch and one that is open for the very 
> much needed restructuring of the code.
>
> What do you think?
>
> Regards,
>
> Rainer


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message