tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Rossbach ...@objektpark.de>
Subject Re: tomcat 5.5 Cluster and JMX Re: svn commit: r379938 - /tomcat/container/tc5.5.x/modules/cluster/to-do.txt
Date Thu, 23 Feb 2006 12:51:40 GMT
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


Mime
View raw message