[Openais] Re: A bug for AMF

[Steven Dake]

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.


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