[Openais] Re: messages and cluster generation

Steven Dake sdake at mvista.com
Thu Sep 16 13:35:04 PDT 2004


On Thu, 2004-09-16 at 13:16, Mark Haverkamp wrote:
> 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.
> 

Yup the first one is the transitional config, the second is the regular
config.  In single node configurations, there is only one, the
transitional config.  This needs to be fixed (and is a bug).

If you mean by the phrase "all get recieved" "all get delivered" then
yes.  received occurs when the processor receives a remulticast or an
original multicast.  Delivery occurs when the delivery function is
called notifying the services of the new message contents.

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




More information about the Openais mailing list