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
Date Thu, 23 Feb 2006 13:28:56 GMT
couple more changes coming up.

today in the NIO setting waitForAck="false" means essentially async, and 
waitForAck="true" means sync, meaning that the session will get updated 
across the entire cluster before returning to the request.

in the next release waitForAck="true" means that the receiving will ack 
the message when it gets it, not after it is processed.
Instead there will be a WaitForCompletion interceptor added to simulate 
today's behavior.

in similar way, we will add a RPCInterceptor creating the new feature to 
allow to receive a message response to your send.
This feature is required for state transfer to become correct.

another useful interceptor is the MemberEstablishment interceptor which 
will queue all messages for a specific sender until all state has been 
transferred. Currently this is another not so elegant, but working(!) 
solution in the clustering code.

another useful interceptor is the FragmentationInterceptor that breaks 
up large messages into many smaller and then re-assembles them on the 
other end.

another useful interceptor is the SendReceiveStatistics interceptor 
which can collect stats for data sent

another useful interceptor is the PersistentStateInterceptor which can 
store all messages ever sent in persistent storage to recreate state.

another useful intercepor is the LoggingInterceptor that logs all the 
messages sent and received

with the new design, the ability to add new complex features becomes 
endless and extremely modular. This was my intention when i started the 
project, but unfortunately I fell off the face of the planet into the 
commercial software world, and in 5.5 the components took on a new 
direction.

I hope all these examples make it abundantly clear that the new design 
is extremely powerful, much needed and a huge improvement on how the 
code base looks today.

Filip


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: 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