[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