[Openais] Re: Implement configuration change support.

[SAKAI MIYOTAKA]

Steve ,

Steven Dake wrote:

>Sakai-san
>
>I have copied the openais mailing list so others can benefit from our
>exchanges.
>
>Your ideas are good I've included some comments inline.
>
>On Mon, 2004-09-06 at 14:31, SAKAI MIYOTAKA wrote:
>  
>
>>Steve ,
>>
>>TODO list says ,
>>"Very Important: Implement configuration change support. This includes
>>partitions."
>>I think so too.
>>
>>I suppose this could be done , without a lot of changes of dsm and
>>interfaces to other aisexecs .
>>
>>My idea is followings
>>
>>To implement configuration chage is to implement .config _fn
>>in service_handler amf_service_handler .
>>If .config_fn is called and left nodes exist ,
>>    
>>
>
>There is already a function called within the service handler for
>configuration changes.  The problem is that the configuration change
>handler isn't implemented for AMF, CKPT, or EVT.  CLM is implemented,
>though.
>
>The interface in the service handler is:
>.confchg_fn (which is defined in the amf to 0 at the moment).  The
>function call looks like this:
>
>static int amf_confchg_fn (
>    struct sockaddr_in *member_list, int member_list_entries,
>    struct sockaddr_in *left_list, int left_list_entries,
>    struct sockaddr_in *joined_list, int joined_list_entries);
>
>
>  
>
>>.config_fn calls dsmEnabledUnlockedTransitionDisabledUnlocked to
>>components in left nodes.
>>If joined nodes exist , .config_fn calls a function changed
>>message_handler_req_amf_componentregister.
>>After calling message_handler_req_amf_componentregister ,
>>message_handler_req_exec_amf_componentunregister
>>is invoked . In that case ,
>>message_handler_req_exec_amf_componentunregister does must not
>>call libais_send_response .
>>    
>>
>
>Right I understand what you desire.  To avoid sending a response to the
>library when doing a component unregister, use the
>"componentUnregister()" function in amf executive.
>
>You will probably need an added function component_register which
>behaves the same as componentUnregister.
>
As you pointed out , I misstook .

What I really want to say is followings .

After calling message_handler_req_amf_componentregister ,
message_handler_req_exec_amf_componentregister
is invoked . In that case ,
message_handler_req_exec_amf_componentregister avoid sending
response to the library.  

Anyway , enough design is needed .


>>But my concern is performance .
>>If a aisexective has a lot of componet , when a certain node joining ,a
>>lot of UDP packets sende
>>    
>>
>
>I'd focus on correct operation instead of performance at this point. 
>I'd expect the failover happens in less then 5ms in most cases today and
>if we can keep this sort of performance we should be satisified.
>
OK .
In this case , correct operation is necessary .

>>In that case , it might be neccessary to chage EVS .
>>( For example , Token keeping during several messages sending . )
>>.
>>    
>>
>The gmi (low level group messaging interface) keeps a token for as many
>messages as can be sent without overflowing local or remote buffers. 
>This happens to be set  to 20 at the moment, but can be increased.  I've
>run it at 80 without packet loss, but slower CPUs have problems with
>that.  Eventually we need to rework the flow control so it determines
>the maximum flow control rate for the processors that make up the
>configuration.
>  
>
I didn't understand how gmi behave . Thank you for telling me .
Most caese 20 is enough .

>>I would like to implement this changes , if you don't mind and allow me .
>>My idea showed above is verry simple , but I know it is necessary to
>>design enough .
>>when implemening this , your advice must be needed .
>>Please agreed with me and tell me deadline .
>>( Pleaes give me enough time )
>>    
>>
>
>Your contributions for partitioning would be wonderful!  I'd suggest
>keeping in mind what should happen when two seperate partitions occur
>and operate simulatenously.  
>
I understand .

>This is a big problem with the AIS AMF
>spec.  But if we can get it to work for the most common case where only
>one partition remains after a configuration change, we should be
>satisified for our next release.
>
Sure .
First of all , I will implement symply where only one partition remains
after a configuration change .

>We are hoping to have a release by the end of the year including CLM,
>EVT, AMF, CKPT and the recently added EVS.  If someone develops the two
>remaining services between now and November, we may also add support for
>those.  The release should have some basic man pages.  We should also
>strive for 90% code coverage with the test suites we have available.
>
>How does this timeline work for you?
>
OK .
I would like to confirme that I have to do .
My responsiblility is to implement configuration change suport for AMF
, and that is simple implemantaion where only partition remains
after a configuration change .
Next step , after consulting you , I would like to decide what I do .

>>By the way , to understand amf module , I made document attaced this
>>message .
>>This document isn't well reviewed , but it help someone understand amf
>>module .
>>if you allow me , I send it to mailing list .
>>And give me some advice .
>>    
>>
>
>This is really great work!  If it is ok with you, I'll post this to the
>openais web site so other people can see it.  Let me know if that is ok.
>
It is OK with me .
I 'm embarassed because of my terrible English .
I'd better change appropriate the each diagram title .
What do you think .
Any way , I'm happy that the document I made helps someone who
understand amf module .

Is bitkeeper necessary to implement ?
Do you have another way ?
( I don't have the bitkeeper licence .)
Or should I have bitkeepr licence ( for future ) ?

Thanks .
- Miyotaka Sakai .