[Openais] Re: [saf-open] Open channels, retained events, cluster partition merges.

Steven Dake sdake at mvista.com
Thu Feb 10 11:15:07 PST 2005


Mark

I wasn't contributing during the specification of this wording of the
unlink so I am unsure.  This question might be appropriate for the
saf-open list though.  Perhaps some of the saf spec developers may have
some ideas.

On Thu, 2005-02-10 at 09:10, Mark Haverkamp wrote:
> On Wed, 2005-02-09 at 18:43 -0700, Steven Dake wrote:
> > Mark
> > in 3.1.2 Event Channels - "An event channel enables multiple publishers
> > to communicate with multiple subscribers.  It is global to a cluster and
> > is identified by a unique name".  
> > 
> > As a result, I don't think its possible to have two seperate channels
> > with the same identifier from two previously merged partitions join one
> > partition as two seperate channels.  In this merge case, I believe the
> > merge should result in one fully merged channel.
> 
> I do agree with this.  It was my intention to implement it this way.  I
> just wanted to get some other opinions first and make sure that others
> thought so too.
> 
> > 
> > Ideally we don't want to exchange retained events that of which each
> > processor is already aware.  One optimization would be to communicate a
> > list of the event identifiers (perhaps with ring ids associated with
> > them) instead of exchanging the full event.
> 
> Probably so, maybe this can be an optimization for another time.
> 
> > 
> > The reopen wording around line 26 of page 36 provides the scenario I
> > think your question involves needs some work.  Here is the scenario:
> > processor ( 1 2 3 4 ) with channel Z open 
> > (1, 2) split from (3, 4)
> > (12) unlinks channel Z
> > (1) creates channel Z (2nd instance)
> > (3, 4) doesn't unlink 
> > 
> > 
> > I believe in this scneario, (3, 4) should be unlinked.  For this to
> > happen, (1, 2) would have to remember it had Z (with some other unique
> > identifier, perhaps the configuration identifier under which the channel
> > was created) so someone in (1, 2) could send an unlink command to (3, 4)
> > during synchronization.  Part of this command would have to be the
> > configuration under which it was issued to ensure an unlink doesn't come
> > for a later configuration because of queueing in totemsrp.
> > 
> > Then if:
> > 
> > (3, 4) close their channels
> > (3, 4) is then unlinked because of the unlink command sent by the
> > representative of (1, 2)
> > if (3, 4) open a channel Z, they open the 2nd instance
> 
> Here is where I'd like to get input from someone who had a part in
> specifying the unlink API.  Were splitting and merging partitions
> considered when the API was created? I'd like to understand the reason
> for having the unlink be like unlinking a file and what possible
> practical use it could have.  I'd rather not spend a lot of time trying
> to reconcile a bunch of unlinked channels in split partitions when they
> merge if no one has a use for it.
> 
> The simple solution is to merge active channels.  Ignore unlinked
> channels.  I know that you could possibly be merging channels that have
> been created/unlinked/created again and so on while a partition was
> split.  The whole situation seems somewhat bizarre anyway and since the
> specification doesn't address these kind of details we need to do
> something somewhat reasonable and make sure that we document it.
> 
> 
> > 
> > The configuration identifier would be very valuable in uniquely
> > identifing a channel instance.
> > 
> > Would you like the config id sent in the configuration change?  I think
> > this makes alot of sense.  We have talked about this before and I
> > suspect it will be necessary for checkpoints.
> 
> It may be useful to have.  I'm trying to remember what I needed it for
> before.
> 
> > 
> > I hope my ramblings have been of some use:)
> 
> Hopefully it will encourage some more opinion and discussion on the
> subject.
> 
> Thanks,
> Mark.




More information about the Openais mailing list