Hey Filip
can you tell us more about the your change plans, and how I can help?
I thing the current cluster changes are a high risk and it was better
to start those changes for TC 6. When next cluster generation is
stable, then we make a backport to TC 5.5
One of me ideas is, that we build a cluster regession test suite. I
start a ant base cluster config generation project and hope I
finished this work at middle of next month.
Peter Roßbach
Q: Break your ReplicationListener/ClusterReceiverBase change the
cluster default mode ?
Q: Have you test your changes with the other ClusterReceiver class
SocketReplicationListener ?
see other comments
Am 23.02.2006 um 14:07 schrieb Filip Hanik - Dev Lists:
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.
Please, can you post a example or an proposal for that change!
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.
This timing is one of my problems.
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.
OK, What design change you plan? All message pass a interceptor chain?
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]
