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.
+1
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).
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
