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