You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rainer Jung <to...@kippdata.de> on 2006/02/23 14:41:25 UTC
Cluster maintenance and improvement
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
Filip Hanik - Dev Lists wrote:
> new features and new development has historically always been done
> against the head revision.
> If you want to put something into maintenance, then that becomes a branch
>
> for example
>
> VERSION
> | ---> HEAD REV ---> NEW DEVELOPMENT
> |
> | ---> BRANCH ---> MAINTENANCE MODULE
>
> in our case
>
> 5.5.15
> | ---> HEAD REV ---> NEW CLUSTER DEVELOPMENT
> |
> | ---> OLD CLUSTER COMPONENT BRANCH ---> MAINTENANCE MODULE FOR THE
> WAY IT IS TODAY
>
> To calm your nerves a little bit, I don't plan to pull out the JMX, nor
> to make major server.xml conf changes for 5.5.x, but it is on the
> horizon for TC6.
> For 5.5.x the server.xml will remain similar to what it is today, ie,
> almost backwards compatible (minus the changes I already made).
> TC 6 will have a completely new conf.
> TC 5.5.x will have a TC6 style new conf enabled added for the users that
> want to take advantage of plugging in their own message interceptors and
> to do primary/secondary backup replication which I intend to have
> complete by 5.5.16/17 depending on when those releases get cut.
>
> The compression flag will get taken out of the protocol, replaced with a
> default compression interceptor is compress="true". so functionality
> will not change for the users either.
>
> Filip
>
>
>
> Peter Rossbach wrote:
>
>> Hey Filip,
>>
>> what I see is you want make an innovative step. Great, I m very
>> motivated to
>> help that we implement a next generation.
>>
>> But, why do we this implementation not inside a sandbox, branch or
>> separate module?
>>
>> Last year I learned that big changes are great, but it is easy to make
>> failures at very little
>> details, like the compress flag bug. To design a new implementation is
>> risky. A lot of
>> projects and people now use very succesfull the current tomcat 5.5.15
>> cluster. Some people are
>> waiting that we release the cross context replication to support
>> portal development. Please, I do not want to stop the innovation, but
>> why do we not start the new cluster design at a separate module and
>> set the current code base at maintaince mode?
>>
>>
>> Peter Roßbach
>>
>>
>>
>> Am 23.02.2006 um 12:59 schrieb Filip Hanik - Dev Lists:
>>
>>> Peter Rossbach wrote:
>>>
>>> >I have add the compress flag inside the protocol.
>>> >It is usefull to send message with an without compression.
>>> >For short messages it is not usefull to compress, it is an overhead.
>>>
>>> There is no question whether compression is useful or not.
>>> The compression flag should have never been added in the protocol in
>>> the first place,
>>> Compression can and should be done on a higher level, and the
>>> algorithm should be pluggable.
>>> Adding it to the protocol is like adding a compression flag to a TCP
>>> frame, and its a hack,
>>> And it caused 4 stable releases of tomcat to be broken.
>>>
>>> The flag should have been a flag in the payload,
>>> configurable by the component requesting to send the data as that
>>> component is suitable for making that decision
>>>
>>> compression will still be configurable on a per message basis, but
>>> with a different design.
>>>
>>> >Before 5.5.15 you made a vote that we carefull with protocol changes,
>>>
>>> I didn't make a vote, I advised against it, as if you don't
>>> understand the code as it is pretty detailed and complex, then you
>>> shouldn't be changing it without a full set of regression tests. 4
>>> broken releases should testify to that.
>>>
>>> >Why you now change so much inside one minor tomcat release ?
>>>
>>> Cause it is long needed and long awaited. The way the code got
>>> cluttered in 5.5 with JMX,core replication, io and session
>>> replication all mixed together, means that I cant extend nor can I
>>> implement any useful features. For example, if I wanted to implement
>>> a ComplexTcpCluster class, I have to rewrite all JMX code again, I
>>> have to rewrite all statistics code again, I have to basically
>>> rewrite session replication again. This was never the intention of
>>> this module. The module should provide for much flexibility.
>>>
>>> >Why do you think we must move the cluster JMX MBean code?
>>>
>>> For the exact reasons above. I could have written the entire module
>>> in one single class, JMX, IO, session logic, member logic. But there
>>> was a reason I didn't. Flexibility. Hardcoding JMX against code is
>>> not flexible. Instead the right way is to build the MBeans against an
>>> interface, cause I can change the underlying component without having
>>> to rewrite the JMX code. The way it is now is doesn't allow for this.
>>>
>>> >The most tomcat components have no separate MBean classes
>>>
>>> and this is a good thing? probably not, but and the rest of the
>>> components do, does not set a precedence. Otherwise, if we had one
>>> bad class, then all others should follow?
>>>
>>> >When we move to separate classes we get
>>> >a lot of classes with redundant get/setter attributes and operation
>>> signatures.
>>>
>>> not at all, if you move it to a separate MBean class, I can have 50
>>> different cluster implementations
>>> The way it is now, I would have 50 different MBeans, now that is
>>> redundancy. The way I am suggesting, you will have one at all times.
>>>
>>> >The reasons
>>> >behind I added the JMX code direclty into the cluser component
>>> implementation are:
>>>
>>> JMX has been added to several component, not just the cluster class.
>>> for reasons mentioned above, this is not suitable.
>>>
>>> >-1 for this change.
>>>
>>> I would be careful putting -1 out there, it causes a lot of friction,
>>> especially when they have no justification.
>>> I am working on a improved design, a design that was intended from
>>> the beginning but I got sidetracked with another job not giving me
>>> the time to complete the full circle. I now have that opportunity and
>>> intend to see it through. If you want to be a part of it, I suggest
>>> you come with constructive ideas to move the project forward and not
>>> just veto changes with no justifications. If we didn't want this
>>> project to improve we would still be using Tomcat 3, but the world of
>>> hi-tech changes everyday. All of those changes have the intention for
>>> improvements, not all of them succeed. But that is nature of the
>>> industry we are in.
>>>
>>> I hope this answers all your concerns and makes you redraw your veto
>>> or justify it with a better suggestion.
>>> best regards,
>>> Filip
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: New clustering module proposal - WAS: Long rants
Posted by Yoav Shapira <yo...@apache.org>.
Sounds reasonable to me, +0 as I don't really intend to work much on
clustering stuff myself ;)
Yoav
On 2/23/06, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
> Remy Maucherat wrote:
> > Filip Hanik - Dev Lists wrote:
> >> +1 from myself
> >
> > I think one day, I ought to make a proposal and then veto it.
> >
> Just wait until age catches up with you, you will! :)
>
> > This sounds reasonable.
> >
> Lazy consensus, nice.
> (http://www.apache.org/foundation/voting.html#LazyConsensus) :)
>
> Filip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: New clustering module proposal - WAS: Long rants
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Costin Manolache wrote:
> I'm curious, do you need anything in server.xml ?
>
very interesting, and also a possibility. let me think about it, maybe I
will have an epiphany while I work on it.
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: New clustering module proposal - WAS: Long rants
Posted by Costin Manolache <co...@gmail.com>.
I'm curious, do you need anything in server.xml ?
+1 on making it a module, as independent of tomcat version ( or tomcat
in general ) as possible. Add any hooks you need to avoid strong
dependencies. I think the connectors worked pretty well as a
version-independent tomcat module.
I think it would be even better if the clustering modules would be
released independently of tomcat - i.e. as an add-on module, in a
separate download, with it's own config file ( the 'trusted webapps'
have access to internal classes - so it can be even packaged as a .war
:-).
Costin
On 2/23/06, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
> Sounds like there is a consensus amongst folks. So to summarize
> everyones thoughts, let me know if this sounds like a solution agreeable
> to everyone.
>
> 1. Keep 5.5.x as a maintenance module as it was of 5.5.15 + cross context
>
> 2. Break out cluster config from catalina.jar to catalina-cluster.jar
> that way we can enable more than one config
> In Catalina.java have a ClusterRuleSetFactory.getClusterRuleSet()
> that will load the rule set run time.
>
> 3. Create two new modules (to use for TC6 and as an optional library for
> TC 5.5.x)
> a) Name:groupcom
> Lib : catalina-groups.jar
> Purpose: Group messaging component
> b) Name: ha
> Lib : catalina-cluster.jar
> Purpose: session replication logic, context attribute replication
> and other new features
>
>
> Lets gather one round of feedback and then vote so that I can move on
> with new dev.
>
> Filip
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: New clustering module proposal - WAS: Long rants
Posted by Rainer Jung <to...@kippdata.de>.
+1 (non-binding)
Filip Hanik - Dev Lists wrote:
> +1 from myself
>
> Filip Hanik - Dev Lists wrote:
>> Sounds like there is a consensus amongst folks. So to summarize
>> everyones thoughts, let me know if this sounds like a solution
>> agreeable to everyone.
>>
>> 1. Keep 5.5.x as a maintenance module as it was of 5.5.15 + cross context
>>
>> 2. Break out cluster config from catalina.jar to catalina-cluster.jar
>> that way we can enable more than one config
>> In Catalina.java have a ClusterRuleSetFactory.getClusterRuleSet()
>> that will load the rule set run time.
>>
>> 3. Create two new modules (to use for TC6 and as an optional library
>> for TC 5.5.x)
>> a) Name:groupcom
>> Lib : catalina-groups.jar
>> Purpose: Group messaging component
>> b) Name: ha
>> Lib : catalina-cluster.jar
>> Purpose: session replication logic, context attribute replication
>> and other new features
>>
>>
>> Lets gather one round of feedback and then vote so that I can move on
>> with new dev.
>>
>> Filip
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: New clustering module proposal - WAS: Long rants
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> +1 from myself
>
> I think one day, I ought to make a proposal and then veto it.
>
Just wait until age catches up with you, you will! :)
> This sounds reasonable.
>
Lazy consensus, nice.
(http://www.apache.org/foundation/voting.html#LazyConsensus) :)
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: New clustering module proposal - WAS: Long rants
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> +1 from myself
I think one day, I ought to make a proposal and then veto it.
> Filip Hanik - Dev Lists wrote:
>> Sounds like there is a consensus amongst folks. So to summarize
>> everyones thoughts, let me know if this sounds like a solution
>> agreeable to everyone.
>>
>> 1. Keep 5.5.x as a maintenance module as it was of 5.5.15 + cross context
>>
>> 2. Break out cluster config from catalina.jar to catalina-cluster.jar
>> that way we can enable more than one config
>> In Catalina.java have a ClusterRuleSetFactory.getClusterRuleSet()
>> that will load the rule set run time.
>>
>> 3. Create two new modules (to use for TC6 and as an optional library
>> for TC 5.5.x)
>> a) Name:groupcom
>> Lib : catalina-groups.jar
>> Purpose: Group messaging component
>> b) Name: ha
>> Lib : catalina-cluster.jar
>> Purpose: session replication logic, context attribute replication
>> and other new features
This sounds reasonable.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: New clustering module proposal - WAS: Long rants
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
+1 from myself
Filip Hanik - Dev Lists wrote:
> Sounds like there is a consensus amongst folks. So to summarize
> everyones thoughts, let me know if this sounds like a solution
> agreeable to everyone.
>
> 1. Keep 5.5.x as a maintenance module as it was of 5.5.15 + cross context
>
> 2. Break out cluster config from catalina.jar to catalina-cluster.jar
> that way we can enable more than one config
> In Catalina.java have a ClusterRuleSetFactory.getClusterRuleSet()
> that will load the rule set run time.
>
> 3. Create two new modules (to use for TC6 and as an optional library
> for TC 5.5.x)
> a) Name:groupcom
> Lib : catalina-groups.jar
> Purpose: Group messaging component
> b) Name: ha
> Lib : catalina-cluster.jar
> Purpose: session replication logic, context attribute replication
> and other new features
>
>
> Lets gather one round of feedback and then vote so that I can move on
> with new dev.
>
> Filip
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: New clustering module proposal - WAS: Long rants
Posted by Henri Gomez <he...@gmail.com>.
+1 (please)
2006/2/23, Peter Rossbach <pr...@objektpark.de>:
> Sounds very great
>
> +1
>
> many thanks and now I can start very relaxed to my short journey :-)
> Peter
>
>
>
> Am 23.02.2006 um 18:25 schrieb Filip Hanik - Dev Lists:
>
> > Sounds like there is a consensus amongst folks. So to summarize
> > everyones thoughts, let me know if this sounds like a solution
> > agreeable to everyone.
> >
> > 1. Keep 5.5.x as a maintenance module as it was of 5.5.15 + cross
> > context
> >
> > 2. Break out cluster config from catalina.jar to catalina-
> > cluster.jar that way we can enable more than one config
> > In Catalina.java have a ClusterRuleSetFactory.getClusterRuleSet()
> > that will load the rule set run time.
> >
> > 3. Create two new modules (to use for TC6 and as an optional
> > library for TC 5.5.x)
> > a) Name:groupcom
> > Lib : catalina-groups.jar
> > Purpose: Group messaging component
> > b) Name: ha
> > Lib : catalina-cluster.jar
> > Purpose: session replication logic, context attribute
> > replication and other new features
> >
> >
> > Lets gather one round of feedback and then vote so that I can move
> > on with new dev.
> >
> > Filip
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: New clustering module proposal - WAS: Long rants
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
enjoy your trip!
Peter Rossbach wrote:
> Sounds very great
>
> +1
>
> many thanks and now I can start very relaxed to my short journey :-)
> Peter
>
>
>
> Am 23.02.2006 um 18:25 schrieb Filip Hanik - Dev Lists:
>
>> Sounds like there is a consensus amongst folks. So to summarize
>> everyones thoughts, let me know if this sounds like a solution
>> agreeable to everyone.
>>
>> 1. Keep 5.5.x as a maintenance module as it was of 5.5.15 + cross
>> context
>>
>> 2. Break out cluster config from catalina.jar to catalina-cluster.jar
>> that way we can enable more than one config
>> In Catalina.java have a ClusterRuleSetFactory.getClusterRuleSet()
>> that will load the rule set run time.
>>
>> 3. Create two new modules (to use for TC6 and as an optional library
>> for TC 5.5.x)
>> a) Name:groupcom
>> Lib : catalina-groups.jar
>> Purpose: Group messaging component
>> b) Name: ha
>> Lib : catalina-cluster.jar
>> Purpose: session replication logic, context attribute
>> replication and other new features
>>
>>
>> Lets gather one round of feedback and then vote so that I can move on
>> with new dev.
>>
>> Filip
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: New clustering module proposal - WAS: Long rants
Posted by Peter Rossbach <pr...@objektpark.de>.
Sounds very great
+1
many thanks and now I can start very relaxed to my short journey :-)
Peter
Am 23.02.2006 um 18:25 schrieb Filip Hanik - Dev Lists:
> Sounds like there is a consensus amongst folks. So to summarize
> everyones thoughts, let me know if this sounds like a solution
> agreeable to everyone.
>
> 1. Keep 5.5.x as a maintenance module as it was of 5.5.15 + cross
> context
>
> 2. Break out cluster config from catalina.jar to catalina-
> cluster.jar that way we can enable more than one config
> In Catalina.java have a ClusterRuleSetFactory.getClusterRuleSet()
> that will load the rule set run time.
>
> 3. Create two new modules (to use for TC6 and as an optional
> library for TC 5.5.x)
> a) Name:groupcom
> Lib : catalina-groups.jar
> Purpose: Group messaging component
> b) Name: ha
> Lib : catalina-cluster.jar
> Purpose: session replication logic, context attribute
> replication and other new features
>
>
> Lets gather one round of feedback and then vote so that I can move
> on with new dev.
>
> Filip
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
New clustering module proposal - WAS: Long rants
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Sounds like there is a consensus amongst folks. So to summarize
everyones thoughts, let me know if this sounds like a solution agreeable
to everyone.
1. Keep 5.5.x as a maintenance module as it was of 5.5.15 + cross context
2. Break out cluster config from catalina.jar to catalina-cluster.jar
that way we can enable more than one config
In Catalina.java have a ClusterRuleSetFactory.getClusterRuleSet()
that will load the rule set run time.
3. Create two new modules (to use for TC6 and as an optional library for
TC 5.5.x)
a) Name:groupcom
Lib : catalina-groups.jar
Purpose: Group messaging component
b) Name: ha
Lib : catalina-cluster.jar
Purpose: session replication logic, context attribute replication
and other new features
Lets gather one round of feedback and then vote so that I can move on
with new dev.
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cluster maintenance and improvement
Posted by Peter Rossbach <pr...@objektpark.de>.
Hey Rainer, Filip and Remy,
Am 23.02.2006 um 17:20 schrieb Rainer Jung:
> Hi Remy,
>
>>> 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.
>>
>> It could have that tomorrow.
> ...
>> I agree with Peter: it's obvious no one should be doing major
>> refactoring of existing components in 5.5.x. You could create a
>> separate "cluster2" module if you still want to do the work in
>> Tomcat 5.5.x, however.
>
> So in general we have three options:
>
> A) maintenance branch inside 5.5.15
> B) cluster2 module
>
+1 and revert the changes at the current tomcat cluster head I think
Revision 366257 5.1.2006 or a little bit later.
Then we can make a separate jar download for cluster2 and when is
stable, we change the default at the tomcat 55 distribution.
> C) making changes in TC 6
>
> Whichever way we choose, I think we need two lines of development:
>
> a) one which tries to stick closely to the 5.5.15 code and only
> picks up security fixes and changes needed to keep compatibility
> with 5.5.x.
>
I think we integrate the cross context replication and some of the
fixes from Filip inside the TC 5.5.15 cluster module code.
> b) another one which gets all the refactoring, new features and
> improvements.
>
> We have to make decisions:
>
> - maintenance for a): If we let die a) for TC 6, we should document
> that decision, so would deprecate a) now. This sounds a little
> harsh, but that's in fact what we then do. It would be nice to
> support a) at least 12 months after announcement of deprecation.
>
> - release bundles: I think a) and b) should be available for
> download when a new 5.5 release is done. I don't really care about
> having seperate download file or not.
>
I thing it is easy to have seperate download files
+1
> - default configuration entries in server.xml
>
+1, from current cluster module and later from new cluster2 state.
> Concerning A), B) or C):
>
> Remy: what do you think, about how long dows it take to make a
> first alpha releaseof TC 6. I didn't follow closely the state of
> Specs and implementations. I expect that to still need 2 to 3
> months. If I'm right, that means C) will not work out for Filip,
> because then he lacks the necessary amount of users playing around
> with the new code.
>
> Decision between B) and C) depends more on the kind of message one
> needs to send to the user base. My impression is, that at the end
> the cluster code will have huge differences to it's state today and
> it would be more correct to have cluster2. But I could live with
> all parallel options, as long as we keep the old code compatible
> with 5.5.x and we document the plan for the future (maintenance/
> deprecation) for the user base.
>
I like to have a new cluster2 module inside Tomcat 5.5. After we
finish and have a stable cluster2 we move it also to tc6. I can
maintain the current 5.5.15 implementation stage.
> Rainer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cluster maintenance and improvement
Posted by Rainer Jung <to...@kippdata.de>.
Hi Remy,
>> 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.
>
> It could have that tomorrow.
...
> I agree with Peter: it's obvious no one should be doing major
> refactoring of existing components in 5.5.x. You could create a separate
> "cluster2" module if you still want to do the work in Tomcat 5.5.x,
> however.
So in general we have three options:
A) maintenance branch inside 5.5.15
B) cluster2 module
C) making changes in TC 6
Whichever way we choose, I think we need two lines of development:
a) one which tries to stick closely to the 5.5.15 code and only picks up
security fixes and changes needed to keep compatibility with 5.5.x.
b) another one which gets all the refactoring, new features and
improvements.
We have to make decisions:
- maintenance for a): If we let die a) for TC 6, we should document that
decision, so would deprecate a) now. This sounds a little harsh, but
that's in fact what we then do. It would be nice to support a) at least
12 months after announcement of deprecation.
- release bundles: I think a) and b) should be available for download
when a new 5.5 release is done. I don't really care about having
seperate download file or not.
- default configuration entries in server.xml
Concerning A), B) or C):
Remy: what do you think, about how long dows it take to make a first
alpha releaseof TC 6. I didn't follow closely the state of Specs and
implementations. I expect that to still need 2 to 3 months. If I'm
right, that means C) will not work out for Filip, because then he lacks
the necessary amount of users playing around with the new code.
Decision between B) and C) depends more on the kind of message one needs
to send to the user base. My impression is, that at the end the cluster
code will have huge differences to it's state today and it would be more
correct to have cluster2. But I could live with all parallel options, as
long as we keep the old code compatible with 5.5.x and we document the
plan for the future (maintenance/deprecation) for the user base.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cluster maintenance and improvement
Posted by Peter Rossbach <pr...@objektpark.de>.
Many thanks!
I thing the best way is to move the new cluster implementation at a
new cluster2 module.
With the current cluster build system it is easy to generate and copy
the calalina-cluster.jar to tomcat local build directory.
The only problem currently is ClusterRuleSet must be move from
catalina core to the cluster module.
Peter
Am 23.02.2006 um 16:50 schrieb Remy Maucherat:
> Filip Hanik - Dev Lists wrote:
>> 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.
>
> It could have that tomorrow.
>
Great!
>> 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
>
> JBoss clustering doesn't have primary/sec, and many people are
> still using it. It would be a useful feature for sure, but not
> having it doesn't mean people aren't going to use clustering.
>
I also have a lot of customer that work very succesful without
primary/sec.
>> 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.
>
> Personally, I've had the impression that virtually all builds had
> issues of some sort, although 5.5.9 might have been fine.
>
>> 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.
>
> I agree with Peter: it's obvious no one should be doing major
> refactoring of existing components in 5.5.x. You could create a
> separate "cluster2" module if you still want to do the work in
> Tomcat 5.5.x, however.
>
+1
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cluster maintenance and improvement
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> 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.
It could have that tomorrow.
> 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
JBoss clustering doesn't have primary/sec, and many people are still
using it. It would be a useful feature for sure, but not having it
doesn't mean people aren't going to use clustering.
> 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.
Personally, I've had the impression that virtually all builds had issues
of some sort, although 5.5.9 might have been fine.
> 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.
I agree with Peter: it's obvious no one should be doing major
refactoring of existing components in 5.5.x. You could create a separate
"cluster2" module if you still want to do the work in Tomcat 5.5.x, however.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cluster maintenance and improvement
Posted by Peter Rossbach <pr...@objektpark.de>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cluster maintenance and improvement
Posted by Rainer Jung <to...@kippdata.de>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Cluster maintenance and improvement
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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