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 13:45:35 GMT
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: 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


Mime
View raw message