Table of Contents |
---|
References
Jira | ||||||
---|---|---|---|---|---|---|
|
Assumptions
Assumption | Notes | Sign-off | ||||
---|---|---|---|---|---|---|
1 | Topic name extracted from Subscription ID | 2 | One client can have multiple subs | 3|||
2 | Topic is setup | correct and can writecorrectly (by clients) and NCMP will 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
kieran 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
ReqFunctional
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 Proposed by CPS "<topic-name>---<unique-id>
eg. a client then would create (or own) a topic 'our.cm-channel' then by convention they can create subscription ids like so:
'our.cm-channel---0001' 'our.cm-channel---0002' 'our.cm-channel---4g-cell-subscription' 'our.cm-channel---5g-cell-subscription" Assumption - We'll get a subscriptionId and topicname | tbc, kieran mccarthy / Csaba Kocsis to review | and comeback and come back. Currently NCMP receives event and it doesn't contain Topic name. Issue - NCMP still need topic name.
Event format shall be subscriptionId and topicnamekieran mccarthy Kolawoe Adebisi-Adeolokun Priyank Maheshwari Csaba Kocsis long term focus shall be on the rest interface(push) for rapps
Deperio. this as well on the release page till we get around discussing the new subscriotion epic. |
2 | Client-defined topic | 2Client application shall ONLY receive notification they subscribed on | |||
3 | Client-defined topic | Client application shall not see notification they did not subscribed on | |||
4 | 5Client-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 |
incoming 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 | NCMP shall support horizontal scaling to support |
>> 150M CM notification change events (Daily) |
| ||
4 | NCMP shall support processing CM notification change events with the following subscription profile :
|
Upto a 150M cm-handle is incoming the outgoing should not exceed >200m CM handle per NCMP
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 | 1
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)