[Openais] Re: A bug for AMF

[Miyotaka Sakai]

Steve ,

Steven Dake wrote:
> comments inline
> 
> On Mon, 2004-10-04 at 09:00, Miyotaka Sakai wrote:
> 
>>Steve,
>>
>>my responses inline .
>>
>>
>>Steven Dake wrote:
>>
>>>Miyotaka-san
>>>comments inline
>>>
>>>On Sat, 2004-10-02 at 13:27, Miyotaka Sakai wrote:
>>>
>>>
>>>>steve,
>>>>
>>>>I've found a bug for AMF and made a patch .
>>>>I would like you to review this patch .
>>>>
>>>>Several gmi_mcast messages couldn't be delivered .
>>>>I changed gmi_mcast's message priorty from GMI_PRIO_HIGH to
>>>>GMI_PRIO_RECOVERY ,then messages could be deliverd .
>>>>
>>>>If you have another idea, Please tel me.
>>>>
>>>>This patch add several mechanisms to ease to debug .
>>>>( a mechanism is watching AmfComponent contents )
>>>>
>>>
>>>The changing of priorities needs a different solution...  I think I
>>>messed this up for you when I added the recovery plug.  Could you fix it
>>>up?
>>
>>I am sure. I will.
>>
>>
>>>The way it should work is this:
>>>messages sent during recovery (within the amf_confchg_fn function and
>>>all the other messages related to them) should be sent at recovery
>>>priority.  messages sent during normal operation should retain their
>>>current priorities.  Since the state machine must now (with the recovery
>>>plug) send messages at two different priorities depending on what state
>>>the system is in, we need to keep track of the priorities.  It is
>>>possible for the state machine to know the priority at which it should
>>>send messages by placing the priority in the first message that starts
>>>the state transitions.  Then every message that triggers a new message
>>>to be sent should encode the priority of the message to the next state. 
>>>If you need more details please ask.
>>
>>OK.
>>I know what you mean .
>>For exsample ,haStateSetCluster relating amf_confchg_fn uses 
>>GMI_PRIO_RECOVERY ,but others use GMI_PRIO_HIGH.
>>It is possible ,and I 'll fix it .
>>
>>
>>>It is possible that the output queues used in gmi_mcast are full.  In
>>>this case, it is necessary to use gmi_token_callback_create.  Mark
>>>Haverkamp has implemented this in the event service if you need an
>>>example of using it.  This callback will be called the next time it may
>>>be possible to send messages.  The callback should then resend the state
>>>machine message that failed to send on an earlier try.
>>
>>I refered to Mark's implementation and ,I understaned this 
>>implementation. Please take some time to implement this .
>>
> 
> 
> cool this is a pretty hard objective but if we can get this issue fixed,
> we will have a much more reliable system...
> 
> 
>>>Why the signal stuff in main.c?
>>
>>I want to konw AmfComponents cotents at the time when I want to know .
>>( I don't know when I want to know AmfComponents contens.
>>   It is different in each debug situation. )
>>In that case ,Most easy inmplementation is signal .
>>If you have ,Could you tell me another idea ?
>>
> 
> 
> So when you get a SIGUSR2, you want the component state to be dumped? 
> I'll provide some comments on the specific implementation in your patch
> attached email...  
> 
> We may want an exec_exit_fn added to the service_handler structure so
> that when ais_done is called, we can call an exit routine for all of the
> services.  but I'm not sure if this would help if you wanted to dump
> state at any time, not just on exit.

I want to dump AmfComponent state whenever I want .
Not only when aisexec exit but also when a node join ,when a node leave
,when test program exit ,etc ,,,

In this case ,signal is easy way to do it.

>>>The added debug output looks fine.  Please try to use log_printf instead
>>>of printf though.  Could you check in just the debug output as a
>>>seperate commit after addressing the comment above?
>>
>>I'll change printf into log_print.
>>
>>Thanks
>>- Miyotaka Sakai.
>>
>>
>>>Thanks
>>>-steve
>>>
>>>>If you accept this patch ,I'll check-in .
>>>>Thanks !
>>>>- Miyotaka Sakai.