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

Mark Haverkamp markh at osdl.org
Thu Feb 10 08:10:22 PST 2005


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.

-- 
Mark Haverkamp <markh at osdl.org>




More information about the Openais mailing list