[Openais] Re: messages and cluster generation

Mark Haverkamp markh at osdl.org
Thu Sep 16 13:16:25 PDT 2004


On Thu, 2004-09-16 at 12:45, Steven Dake wrote:
> On Thu, 2004-09-16 at 12:37, Mark Haverkamp wrote:
> > On Thu, 2004-09-16 at 12:06, Steven Dake wrote:
> > > On Thu, 2004-09-16 at 10:16, Mark Haverkamp wrote:
> > > > Steve,
> > > > 
> > > > When I receive a mcast, is there any way to tell which generation of the
> > > > cluster it came from? During a configuration change, I send a mcast from
> > > > the confchg_fn to start a recovery process to send retained messages.  
> > > > If multiple config changes occur, I don't see how I can tell one config
> > > > change mcast from another, when the last one has arrived, etc.  I see
> > > > that gmi generates a memb_conf_id.  Is this the same value on each of
> > > > the cluster nodes?  If it is, could it be passed to the confchg_fn so I
> > > > can tag my mcasts?
> > > > 
> > > > Thanks,
> > > > Mark.
> > > 
> > > Mark,
> > > 
> > > We could add memb_conf_id to the configuration change.  It is the same
> > > on each processor.  In the past I had considered adding it, but couldn't
> > > see an immediate use for it.  I'm not opposed to adding it...
> > > 
> > > I believe what you want should already be present, though.  When a
> > > configuration change occurs, and then multicasts occurs, all those
> > > multicasts will have been sent in the configuration change that last
> > > occured.  If there is a new configuration change, then the new
> > > multicasts will represent that new configuration change (and will be
> > > delivered after the configuration change).
> > > 
> > > I think there may be some problems here with queueing.  Ie: you queue a
> > > message in one configuration, and then the message is sent in a new
> > > configuration because a change happens while the message is queued.  Is
> > > that the problem you are seeing?  If so, I think we could/should fix
> > > this problem in gmi.
> > 
> > I don't know if I'm seeing this or not.  
> > 
> > > 
> > > Does the above help, or do you still think we need the memb_conf_id
> > > passed to the confchg function?
> > 
> > I don't think that I can tell right now which configuration sent a given
> > message, can I?  I guess wanting the memb_conf_id lets me tell which
> > configuration sent a message.  If there is another way to tell, I'll use
> > it.
> > 
> 
> You cannot tell which configuration sent a given message, but you will
> always know that the currently delivered message was sent in the
> configuration specified by the most recent configuration change
> message...  Does this do what you need?
> 
> There may be a queueing problem, stated above with this approach which I
> think we can/should fix elsewhere...

OK, this may do what I need. But the cfgchg_fn still gets called twice
(maybe) per change. Should messages sent from the confchg_fn during the
transitional config all get received before the confchg_fn is called for
the regular config?  If this is true, then I think it's OK.

> 
> > 
> > > What do you intend to do if the memb_conf_id is invalid in the multicast
> > > message?  Ignore the message?
> > 
> > Yes, If I get a message from an older config, I just ignore it and wait
> > for ones corresponding to the current config.
> > 
> > Thanks,
> > Mark.
> > 
> > > 
> > > Thanks
> > > -steve
-- 
Mark Haverkamp <markh at osdl.org>




More information about the Openais mailing list