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