Subject: Disconnected ServiceChange in MG failover

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 25 Jan 2001 15:49:09 -0500

Suppose you had redundant MGs.  The primary fails.  The secondary
takes over.  In the process, transactions were lost.

Shouldn't the secondary MG send ServiceChange with Disconnected?

Is this worth a note in the Implementor's Guide?

Brian

---

From: Tom Taylor <[email-masked]>
Date: Mon, 29 Jan 2001 13:28:29 -0500

How did the secondary know to take over?  Is secondary takeover consistent with the postulate that transactions were lost?  Is the
necessary information not conveyed by ServiceChangeReason?

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 29 Jan 2001 13:58:38 -0500

> How did the secondary know to take over?
I don't think it matters. Whatever the reason, it did.  Given the protocol,
it has to be something proprietary to the implementation.

> Is secondary
> takeover consistent with the postulate that transactions were lost?
Before the MG died, it may have received transactions, but not completed
them.  After it died, but before the secondary MG took over, the MGC may
have attempted to send transactions.

>Is the
What reason?  Restart - no.  Disconnected, maybe, that was the question

Brian

---

From: Hong Staley <[email-masked]>
Date: Mon, 29 Jan 2001 11:53:13 -0800

Hi Brian and Tom,

I just want to clarify the usage of Service Change methods "Disconnected"
vs. "Failover" on Root terminationID.

The "Disconnected" method with "Service Restored" is sent from the MG to the
MGC when the MG had failed earlier, but it was subsequently restored. In
this case, some transactions may be lost and the MGC may wish to use Audit
command to resynchronize its state with the MG's. The reporting MG in this
case could be the redundant MG who just takes over and restores service from
the primary.

On the other hand, the "Failover" method with "MG Impending Failure" could
be sent from the secondary MG to the MGC when the secondary MG wants to
notify the MGC that its primary is out of service and it's taking over.
Unlike the previous case, the audit may not be necessary. And finally, the
"Failover" method with "MGC Impending failure" is normally sent from the MG
to the next controlling MGC when the MG detects a failure of its current
controlling MGC.

Is my understanding correct?

Hong
CopperCom, Inc.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, January 29, 2001 1:59 PM
To: [email-masked]
Subject: Re: Disconnected ServiceChange in MG failover

Brian

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 30 Jan 2001 10:24:27 -0500

ServiceChangeReason is not the same as ServiceChangeMethod.  Anyway, I think
the text spells out fairly explicitly that the method to be used should be
Failover.

> From: Rosen, Brian [mailto:[email-masked]]
> To: Taylor, Tom-PT [NORSE:B901:EXCH];
> [email-masked]
> Subject: RE: Disconnected ServiceChange in MG failover
>
>
>

---

From: Tom Taylor <[email-masked]>
Date: Tue, 30 Jan 2001 10:20:00 -0500

Reviewing the thread, I see my view is different from everyone else's.  I still say that the text describing the Failover method is
fairly clear.  I quote:
6) Failover - sent from MG to MGC to indicate the primary MG is out of service and a secondary MG is taking over.

My own preference would therefore be
Method=failover
Reason= 'warm boot' to indicate loss of transient state ('cold boot' to indicate loss of all state) or 'service restored' to indicate no
loss of state

Have to admit: our methods sound like reasons, and vice versa, but it's too late to change terminology now.

---

From: "Marcello Pantaleo (EED)" <[email-masked]>
Date: Tue, 30 Jan 2001 18:55:55 +0100

Hi,

I don't find the text fairly clear.

6) Failover - sent from MG --Prymary or Secondary????
to MGC to indicate the primary MG is out of service
and a secondary MG is taking over.

IMO it is the Prymary that sends ServiceChange with metho Failover.
I quote:
"
Upon failover, the Primary MG sends a ServiceChange command with a
"Failover" method and a "MG Impending Failure" reason.  The MGC then
uses the secondary MG as the active MG.  When the error condition is
repaired, the Working MG can send a "ServiceChange" with a "Restart" method.
"

But I see not everyone has the same opinion.
What about a text clarification, IG issue?

Marcello