[Openais] Re: confchg_fn, cluster membership, etc.

[Steven Dake]

On Thu, 2004-09-16 at 07:32, Mark Haverkamp wrote:
> On Wed, 2004-09-15 at 16:05, Steven Dake wrote:
> > On Wed, 2004-09-15 at 15:53, Mark Haverkamp wrote:
> > > On Wed, 2004-09-15 at 15:41, Steven Dake wrote:
> > > > Mark,
> > > > 
> > > > I have had a look at the clm_get_by_nodeid and evt.c and have come to
> > > > the conclusion that it is not possible to use this function in a
> > > > configuration change function.
> > > > 
> > > > This is because some of the information cannot be gathered until after
> > > > the configuration change has occured.  The nodejoin message is never
> > > > sent until after a configuration change and the nodejoin message
> > > > contains the node information (such as the timestamp of the boot, name,
> > > > etc).  I'd rather not add all of that information into the gmi form
> > > > token because we use too much space already for the membership algorithm
> > > > and it would reduce scalability in the future.
> > > > 
> > > > One workaround to this problem is to develop a evt configuration change
> > > > handler that doesn't use clm_get_by_nodeid.
> > > > 
> > > > For the join case, make evt_add_node send an executive message "add a
> > > > node" (with the ip address) and make the executive message handler match
> > > > the current body (with message decoding operations) of the evt_add_node
> > > > function.
> > > 
> > > I was kind of working in that direction.  Although, if you look at my
> > > EVT_CONF_CHANGE case in the patch for bug 43, I had to check for the
> > > cluster node pointer being NULL because I don't always get a cluster
> > > node, even there.
> > > 
> > 
> > Yes you will need the EVS plug in order for this scheme to work
> > correctly 100% of the time.
> 
> What is an evs plug-in?  Is that different than the evs service?
> 

Not evs plugin, its really a plug to stop new high/med/low messages for
the group messaging (gmi).

Here is how it works.  There are three interfaces added to gmi:
int gmi_recovery_plug_create (
    gmi_recovery_plug_handle *handle_recovery);

int gmi_recvoery_plug_destroy (
    gmi_recovery_plug_handle handle_recovery);

int gmi_recovery_plug_unplug (
    gmi_recovery_plug_handle handle_recovery);


In a service's aisexec_init_fn, gmi_recovery_plug_create is called if
the service doesn't want low/med/high priority messages to be sent by
any service until it has finished recovering its state (not messages).

Then after recovery of the service has completed, the service calls
gmi_recovery_plug_unplug.

A bitmap will be added to the token representing positions in the
memb_list that have been unplugged.  Once the bitmap has all positions
set for all members, high/med/low priority messages may be sent.  If the
bitmap is not completely set, then no high/med/low messages may be
sent.  After a regular configuration change, the bitmap will be set to
zero in the token.

A bitmap position is set by the processor once all handles that have
registered with gmi_recovery_plug_create have executed a
gmi_recovery_plug_unplug after the configuration change.

Regards,
-steve

> Mark.