tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
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 11:59:35 GMT
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


Mime
View raw message