Ack for both with one comment.
Contents still shows headless word:
184.108.40.206 Behavior during absence period of SCheadless 22
220.127.116.11 Recovery handling after SC absence periodr headless
On 22-Sep-16 5:24 AM, Minh Hon Chau wrote:
> osaf/services/saf/ntfsv/README.HYDRA | 26 +++++++++++++-------------
> 1 files changed, 13 insertions(+), 13 deletions(-)
> diff --git a/osaf/services/saf/ntfsv/README.HYDRA
> rename from osaf/services/saf/ntfsv/README.HYDRA
> rename to osaf/services/saf/ntfsv/README_SC_ABSENCE
> --- a/osaf/services/saf/ntfsv/README.HYDRA
> +++ b/osaf/services/saf/ntfsv/README_SC_ABSENCE
> @@ -1,4 +1,4 @@
> -SCs outage support in NTF
> +SCs absence support in NTF
> @@ -6,19 +6,19 @@ General
> As support of cloud deployment use case which both SCs possibly are brought
> -the NTF service does not have to provide its full functionality during SCs
> -but it must responsively maintain the interface toward NTF client. It's
> aimed to
> -make the NTF client not being aware of SCs outage, some APIs provided to
> -are just temporarily unavailable. Finally, NTF functionality as well as all
> -APIs can resume operationally after one of SCs comes up. This requires the
> -client incorporates to implement retry mechanism, which has already been
> +the NTF service does not have to provide its full functionality during SC
> +period but it must responsively maintain the interface toward NTF client.
> +aimed to make the NTF client not being aware of absence of SCs, some APIs
> +to client are just temporarily unavailable. Finally, NTF functionality as
> well as
> +all NTF APIs can resume operationally after one of SCs comes up. This
> requires the
> +NTF client incorporates to implement retry mechanism, which has already been
> documented in NTF Programmer Guide (4.5).
> The proposed solution must have the following implementation:
> -1. NTF Agent must return SA_AIS_ERR_TRY_AGAIN during SCs outage in most of
> +1. NTF Agent must return SA_AIS_ERR_TRY_AGAIN during SCs absence period in
> most of APIs
> required to communicate with NTF server.
> 2. Once SC comes up (also known as NTF server is started), NTF Agent will
> @@ -84,7 +84,7 @@ 7. saNtfNotificationReadNext
> can be considered as the last notification successfully been read, from
> NTF Agent can use to find the next notification that the client wishes.
> this continuous read is not supported since notifications are not
> - after SC outage.
> + after SC absence period.
> 8. saNtfNotificationReadFinalize
> Return SA_AIS_ERR_TRY_AGAIN if NTF server is unavailable.
> @@ -93,16 +93,16 @@ 8. saNtfNotificationReadFinalize
> all invalid clients and return SA_AIS_OK if all operations succeed.
> 9. saNtfDispatch
> - Once NTF Agent detects that the NTF Server is up after period of outage,
> NTF Agent
> - will send dummy callback to subscriber's mailbox to trigger saNtfDispatch
> call. From
> - saNtfDispatch, Agent silently registers all invalid clients and subscribe
> + Once NTF Agent detects that the NTF Server is up after absence period of
> SCs, NTF
> + Agent will send dummy callback to subscriber's mailbox to trigger
> saNtfDispatch call.
> + From saNtfDispatch, Agent silently registers all invalid clients and
> subscribe for
> notification if the client is a subscriber.
> Non-affected APIs and explanations
> The following APIs do not require communication with NTF server, also the
> these APIs manipulate are cached locally in NTF Agent. Therefore they can be
> -normally despite of NTF server state.
> +normally regardless NTF server state.
> 1. Notification allocation APIs for Producer
> 2. Filter allocation APIs for Consumer
Opensaf-devel mailing list