[Openais] Re: A bug for AMF

[Steven Dake]

ok signal works for me as long as we can sort it out so it looks right. 
Maybe what we need is a "aisexec_debugdump_fn" added to the
servicehandler which allows every service to dump debug information :) 
I just wont let the idea go :)

thanks
-steve

On Mon, 2004-10-04 at 14:46, Miyotaka Sakai wrote:
> 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.
>