Versions Compared

Version Old Version 8 New Version 9
Changes made by

Kolawole Adebisi-Adeolokun

Toine Siebelink

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

References

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyCPS-2166

Assumptions

3 correct can write to it4

AssumptionNotes1Topic name extracted from Subscription ID2Sign-off
1One client can have multiple subs

kieran mccarthy, Toine Siebelink  

2Topic is setup correctly (by clients) and NCMP will have write accessMaybe not by client but definitely NOT NCMP responsibility

kieran mccarthy, Toine Siebelink  

3CM Events contain CM Handle IDs (and NOT alternate IDs) so the correct  subscriptions can be identified This could change in the future but has lower priority

kieran mccarthy 

Issues & Decisions

1 2

IssueNotes Decision
1Choose alternative for forwarding

Alternatives
NCMP forwards the CM Data Notification:

  1. as multiple CM Data Notifications on a common external topic with a special header indicating the client-id so the client can filter
  2. as one CM Data Notification on a common external topic with a special header containing ALL  client-ids (Array or String with special token separation)
  3. to topic(s) registered by client(s) during Subscription creation

kieran mccarthy and Toine Siebelink

Option 3 further expanded as functional requirements

2 &

3

2Even if clients specify the topic upon subscription creation, can multiple client share the same topic?Only applies to alternative #3 above

Requirement

Req

kieran mccarthy NO, see also assumption 1

3Characteristics wil be discussed  after functional delivery and some performance testKakfa is assume NOT to be a limiting factor

kieran mccarthy , Toine Siebelink 

Requirements

Functional

comeback 

InterfaceRequirementAdditional InformationSignoff
1Client-defined topic

Topic used for forwarding notification should be based on the client-id which can be extracted from the subscription-id 

Need to agree and document the format of the subscription-id

tbc, kieran mccarthy / Csaba Kocsis  to review and

come back 

2Client-defined topic

Client application shall ONLY receive notification they subscribed on


kieran mccarthy Toine Siebelink  

3Client-defined topicClient application shall not see notification they did not subscribed on

kieran mccarthy Toine Siebelink 

45Client-defined topicSubscription-id shall be in the event headerAlso, this mean multiple event to the same topic.

tbc kieran mccarthy / Csaba Kocsis to review and comeback this requirement as it may also impact performance

Charact
 

agreed NOT to support this for performance reasons and clients can always create multiple subs. if needed

Error Handling


ScenarioExpected BehaviorNotes
1Subscription ID format not correct i.e. cannot extract out a valid topic name


2topic does not exist


3no write access to topic


4cannot find subscription  based on cm handle/path in event


Characteristics

Each NCMP instance shall support 150M 23

ParameterExpectationNotesSignoff
1

incoming CM notification change events

150M Events / day~1,736 Events / second! per NCMP instance! 
2

outgoing CM notification change events per day

200M Events / daycaused by overlapping subscriptions 
3

NCMP shall support horizontal scaling to support > >> 150M CM notification change events (Daily)


  1. Do we need to define a maximum ?
  2. Do we need to define an acceptable overhead ie 2 instance will  (probably)
  1. NOT process 2 x 150M = 300M Events day

4

NCMP shall support processing CM notification change events with the following subscription profile :

  • 40% of subscriptions shall process 5% of all network change notification events
  • 30% of subscriptions shall process 10% of all network change notification events
  • 15% of subscriptions shall process 30% of all network change notification events
  • 9% of subscriptions shall process 50% of all network change notification events
  • 5% of subscriptions shall process 70% of all network change notification events
  • 1% of subscriptions shall process 100% of all network change notification events
4

Upto a 150M cm-handle is incoming the outgoing should not exceed >200m CM handle per NCMP

5

Overlapping CH-Handle

Error Handling


1This breakdown does NOT really affect NCMP performance and does not need to be 'mocked' or simulated exactly for testing purposes
BUT we should test with multiple subscription and 1 out of 3 events wil go to 2 different topics (as per #2)
5

Consider Peak load ? ie. 100M events in 1h





Overview

Gliffy
size1200
displayNameSubscription Merge Example
nameSubscription Merge Example
pageid177080337

CM Data Notifications Overview
Which are of interest to which Client (subscription ID)


Cm HandlePathA-10B-52
1CH-1/p/c1YesNo
2CH-1/p/c2YesYes
3CH-1/p/c3NoYes
4CH-4/p/c2NoYes
5CH-4/p/c3NoYes
6CH-1/p/c4NoNo




Solution Proposal

  1. NCMP (currently) listens to all CM Data Notifications (on an 'internal' topic
  2. NCMP queries its own persistence service to find out which Client(s) are interested in the notifications A-10 and/or B-52 (3 alternatives, see issue #2)