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 ClusterRuleSet.java, 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.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
