Table of Contents |
---|
References
Jira | ||||||
---|---|---|---|---|---|---|
|
Assumptions
Assumption | Notes | 1 | Topic name extracted from Subscription ID | Sign-off | |
---|---|---|---|---|---|
1 | 2 | One client can have multiple subs | 3|||
2 | Topic is setup | correctcorrectly (by clients) and NCMP | can write to itwill have write access | Maybe not by client but definitely NOT NCMP responsibility | |
3 | 4CM 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 |
Issues & Decisions
Issue | Notes | Decision | |||
---|---|---|---|---|---|
1 | Choose alternative for forwarding | Alternatives
| kieran mccarthy and Toine Siebelink Option 3 further expanded as functional requirements | 1 2 & | 23 |
2 | Even if clients specify the topic upon subscription creation, can multiple client share the same topic? | Only applies to alternative #3 above |
Requirement
Reqkieran mccarthy NO, see also assumption 1 | |||
3 | Characteristics wil be discussed after functional delivery and some performance test | Kakfa is assume NOT to be a limiting factor |
Requirements
Functional
Interface | Requirement | Additional Information | Signoff | ||
---|---|---|---|---|---|
1 | Client-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 | comeback come back |
2 | Client-defined topic | Client application shall ONLY receive notification they subscribed on | |||
3 | Client-defined topic | Client application shall not see notification they did not subscribed on | |||
45 | Client-defined topic |
|
agreed NOT to support this for performance reasons and clients can always create multiple subs. if needed |
Error Handling
Scenario | Expected Behavior | Notes | ||
---|---|---|---|---|
1 | Subscription ID format not correct i.e. cannot extract out a valid topic name | |||
2 | topic does not exist | |||
3 | no write access to topic | |||
4 | cannot find subscription based on cm handle/path in event |
Characteristics
Parameter | Expectation | Notes | Signoff | ||
---|---|---|---|---|---|
1 | Each NCMP instance shall support 150Mincoming CM notification change events | 150M Events / day | ~1,736 Events / second! per NCMP instance! | ||
2 | outgoing CM notification change events | 200M Events / day | caused by overlapping subscriptions | ||
3 | per day2 | NCMP shall support horizontal scaling to support > >> 150M CM notification change events (Daily) |
| ||
43 | NCMP shall support processing CM notification change events with the following subscription profile :
| 4 | Upto a 150M cm-handle is incoming the outgoing should not exceed >200m CM handle per NCMP | 5 | Overlapping CH-Handle |
Error Handling
This 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
Solution Proposal
- NCMP (currently) listens to all CM Data Notifications (on an 'internal' topic
- 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)