[Openais] Re: A bug for AMF

Miyotaka Sakai sakai.miyotaka at nttcom.co.jp
Mon Oct 25 08:06:21 PDT 2004


Steve,

Thanks for your advice, and my apologies to you for not
resuponding to your email raight away .

My responses inline.

Steven Dake wrote:
> Conceptually this sounds good.
> 
> Does this patch pass your testing?  If so, then you can commit it to
> provide more opportunities for people to test with the changes.
Yes,it passed my testing ,so I'll commit as soon as possible.

> One more note, I'd prefer you not use amf_exec_synchronize as a function
> name.  the amf_exec_* should be reserved for executive messages.  maybe
> instead amf_syncronize?

I'm sure.

Thanks
- Miyotaka Sakai.

> 
> Thanks
> -steve
> 
> 
> On Thu, 2004-10-21 at 13:06, Miyotaka Sakai wrote:
> 
>>Steve,
>>
>>Thank you for your comments.
>>
>>Responses in line.
>>
>>Steven Dake wrote:
>>
>>>Sakai-san,
>>>
>>>A few comments..  I would like to clean up the coding style of my
>>>original code.  If your interested in this work, could you:
>>>
>>>rename readinessStateSetClusterpriority to
>>>readiness_state_set_group_priority
>>>
>>>rename haStateSetCluster to ha_state_set_group
>>>
>>>rename readinessStateSetApi to readiness_state_set_api
>>
>>Above coding styles you pointed out should be changed.
>>I agree with you and I'll fix those.
>>
>>
>>>I think your on the right track with amf_exec_synchronize.  The place
>>>you call it from amf_componentregister seems a little strange.  I
>>>believe what you are doing in the conditional to select to call this
>>>function checks if the componentregister is from an executive (vs a
>>>library).  Is this correct?  I don't really understand this path..
>>
>>The path to amf_exec_synchrozie like this .
>>
>>* A certain node joining happens.
>>amf_confchg_fn
>>->amf_confchg_njoin
>>  ->component_registerpriority
>>    -> gmi_mcast (MESSAGE_REQ_EXEC_AMF_COMPONENTREGISTER)
>>
>>* Called message_handler_exec_amf_componentregister via
>>amf_aisexec_handler_fns by GMI.
>>message_handler_req_exec_amf_componentregister
>>-> amf_exec_synchronize
>>
>>But this is complicated for nomal component regsitering path.
>>Nomal path is like this.
>>* Application calls saAmfComponentRegister
>>  then message_handler_req_amf_componentregister is called
>>  via amf_libais_handlers by GMI.
>>message_handler_req_amf_componentregister
>>-> gmi_mcast(MESSAGE_REQ_EXEC_AMF_COMPONENTREGISTER)
>>message_handler_req_exec_amf_componentregister
>>
>>I realized these are complicated.
>>To avoid this ,a new IF is needed.
>>For example ,the IF name is  MESSAGE_REQ_EXEC_AMF_SYNCHRONIZE
>>Using this IF ,the path to amf_exec_synchronize is more simple.
>>Like this.
>>
>>* A certain node joining happens.
>>amf_confchg_fn
>>->amf_confchg_njoin
>>  ->component_synchronize
>>    -> gmi_mcast (MESSAGE_REQ_EXEC_AMF_SYNCHRONIZE)
>>
>>* Called message_handler_exec_amf_synchronize via
>>amf_aisexec_handler_fns by GMI.
>>message_handler_req_exec_amf_synchronize.
>>
>>Should I add  the above new IF ?
>>
>>
>>>I had not thought of this until I read your patch... but I think your on
>>>the right track.  Maybe what we need is something like:
>>>
>>>1. synchronize state of all components in system
>>>
>>>then calculate in one step before unplugging the ring the new
>>>ha/readiness states for all components:
>>>
>>>2. transition standby components that should be active to active/in
>>>service (because there are not enough active components)
>>>3. transition active components that should be standby to standby
>>>(because there are too many active components).
>>>4. fail over sg's which now have a broken service group because a
>>>component left the configuration permanently.
>>>
>>>That should provide a correct merge operation even if multiple
>>>processors merge in one configuration change...  The state machine will
>>>have to change to accomidate the new possible state transitions (too
>>>many actives to standby, standby to active after a merge)
>>>
>>>What do you think of this new approach based upon your current work?
>>
>>I understand what you mean ,but I think I've done above comments by
>>using dsmSynchronizeStaus and other changes in the patch.
>>
>>If you think I don't understand what you mean ,Could you give me
>>another advice ?
>>
>>Thanks
>>- Miyotaka
>>
>>
>>>Thanks
>>>-steve
>>>
>>>On Mon, 2004-10-18 at 18:21, Miyotaka Sakai wrote:
>>>
>>>
>>>>Steve,
>>>>
>>>>This Patch is added mesage IF (req_exec_amf_componentregister) change.
>>>>In order to scynchronize component status as quickly as possible ,
>>>>this change is neede ,I think.
>>>>(Or should I add another message IF ? )
>>>>
>>>>Regarding SA_AMF_NOT_RESPONDING :
>>>>In component_unregister () ,SA_AMF_NOT_RESPONDING is needed .
>>>>But in component_register () ,SA_AMF_NOT_RESPONDING isn't needed.
>>>>To avoid sending response to saAmfComponenRegister ,
>>>>this patch takes another way.
>>>>
>>>>Thanks
>>>>-Miyotaka Sakai.
>>>>
>>>>
>>>>Steven Dake wrote:
>>>>
>>>>
>>>>
>>>>>Sakai-san
>>>>>My apologies but I don't see any mails recently with a patch attached
>>>>
>>>>>from you.  Could you resend it?
>>>>
>>>>>Thanks
>>>>>-steve
>>>>>
>>>>>On Mon, 2004-10-18 at 16:02, Miyotaka Sakai wrote:
>>>>>
>>>>>
>>>>>>Steve,
>>>>>>
>>>>>>I would like your comment and advice on the patch
>>>>>>that was attacted to the E-mail I sent.
>>>>>>
>>>>>>I don't mind whether you give me severe comment.
>>>>>>I'll reconsider and fix that.
>>>>>>
>>>>>>By the way, I have other jobs on bugzilla that are 140 and 157.
>>>>>>I'll correct these bug first ?
>>>>>>(I'm going to do that ,after I fix this bug.)
>>>>>>
>>>>>>regards
>>>>>>-Miyotaka Sakai




More information about the Openais mailing list