...
| # | Parameter | Expectation | Notes | Sign-off |
|---|---|---|---|---|
| 1 | Maximum number of cm data subscriptions | 200 | kieran mccarthy confirmed | |
| 2 | Maximum, Average CM Handles per subscription | Max: TBD Avg: 200 | kieran mccarthy to confirm | |
| 3 | Maximum, Average XPaths per CmHandle | Max: Avg: 10 | ||
| 4 | Status update processing time limit | Based on the numbers above working out the current state of each cm handle/xpath combination could be slow! | kieran mccarthy order of 30 seconds (NCMP side) |
...
| Issue | Notes | Decision | ||
|---|---|---|---|---|
| 1 | Is it intended that CM Notification subscription request cover (all) descendants of the given xpath too?! | e.g.. if a child is removed and there is a subscription for the parent node, will a notification be send (grandchild, child leaf updates etc.) I hope NOT! Consider:
| kieran mccarthy descendant not covered by 'basic' paths Wildcard will cover this kind of function in future | |
| 2 | Could xpath point to an element that does not exist (yet) | if not how, how can I client be informed about a create event? | kieran mccarthy yes, xpath can point to things that don't exist yet (not even in the curernt model when an upgraded is pending) | |
| 3 | Should NCMP support re-homing, moving of a CM Handle from one DMI to another? | assume only trough delete & create | kieran mccarthy out of scope | |
| 4 | CM Handle Delete: Should DMI or Clients be sent a subscription update | do NOT delete dmi-subscription entry until owning subscription is deleted Note. LCM is already broadcast (today) |
| |
| 5 | Validation of xpath | options order of implement and also performance cost!
| kieran mccarthy not required right now | |
| 6 | can DMI plugin 'reject' a subscription create (for a given cm-handle-xpath combination) | As NCMP might not validate as per issue#5 the DMI=plugin or component further down might have to reject an invalid xpath... | yes currently DMI can use response to say which cm handles are not accepted i.e. rejected' (but not 'pending') kieran mccarthyconfirms DMI can reject whole subscription | |
| 7 | implementation question: should 'rejected' DMI-subscriptions be stored | not needed as whole subscription should be rejected | kieran mccarthyconfirms | |
| 8 | Dimensioning of DB depends on #cm handles, #subscriptions and #xpaths per subscription, this could be too big for fast processing of updates! | Need to agree maximum and possibly realistic average/total number of entries based on the characteristics above The team is blocked until this becomes clear as it wil affect the way the data needs to be modelled exactly | ongoing but not completed! | |
| 9 | Maximum (error) message size | theoretically all cm handles and all xpaths combinations could be rejected or pending leading to a very large error message! | Toine Siebelink no longer relevant given and max decided | |
| 10 | can each CM-Handle have different set of xpath(s) per subscription | the current 'basic' solution only supports a common set of datastore/xpaths (filter) | kieran mccarthy Yes, clients will create only one subscrption subscription and they might have different needs for differnt different nodes (cm handles) | |
| 11 | can the same cm handle/xpath have different subscriptions with different datastores, does that affect the cm data notifications send (which datastore applies | )) |
| kieran mccarthy datastore included. Although this wiki-page will not be updated where cmHandle+xpath is mentioned as unique entry etc. this should now include a third field: datastore as well. |
| 12 | Will migration from 'basic' be supported | Preferred to ask customers to create new subscriptions | kieran mccarthy no need to support (migration) of 'basic' solution. Development of 'basic' solution can be stopped! | |
| 13 | list v list instances filtering | /p/c1 | kieran mccarthy yes, from NCMP point of view a list and a list entry are different xpaths | |
| 14 | confirm subscription id (currently subscription name + client id) | kieran mccarthy to clarify ASAP ASAP including exact format all prefer a single id-field | ||
| 15 | what subscription details should be send when there is a change (in the union) |
| (after initial meeting) kieran mccarthy & Toine Siebelink agreed that because of the possible size of the union (200x200x10=400,000) it is only feasible to send the delta ie option 1. | |
| 16 | one DMI rejects whole (see decision #6) subscription (affected cmhandles) but other DMI accepts the same subscription, is this possible how to handle | kieran mccarthy only sends message back to client about rejected DMIs i.e. the subscription can be partially 'active' |
Solution Proposals
Current state handling for 'basic' (not merged) subscription create/delete (under development)
| Expand |
|---|
Scenario 1 NCMP Send message to client: Statsu OK (no list with Rejected/Pending)
NCMP Send messge to client: Pending [CH-1, CH-2] Scenario 3 NCMP Send message to client: Rejected [CH-2] Scenario 4: Scenario 4-part a NCMP -> Client : Rejected [CH-4], Pending [ CH-5, CH-6, CH-7, CH-8 ] 4-part b 4-part c |
...
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
* Note 1: given the possible combinations the message to DMI needs to be able to specify different xpaths per cm-handle. So a more complex structure is needed for this even ie. an array of CM Handles objects each having their own list of (target) xpaths!of (target) xpaths!
Note 2: as per decision #11'datastore' should be included in these messages as well
Delete Combinations
| # | Existing Subscription A-10 | Existing Subscription B-52 | Client Delete A-10 Request | DMI Sub update/delete request | Data Model* Before Before | Data Model* After Delete | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | CH-1, [ /p/c1, p/c2 ] | CH-1, [ /p/c1 ] | CH-1, [ p/c2 ] |
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2 | CH-1, [ /p/c1] CH-2, [ /p/c1] | CH-2, [ /p/c1] CH-3, [ /p/c1] | CH-1, [ /p/c1] |
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 3 | CH-1, [ /p/c1] | CH-1, [ /p/c1] CH-2, [ /p/c1] | None |
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
* Note: as per decision #11'datastore' should be included in the 'DMI susbcription' data model too now.
Error-Upon-Error Combinations
...
Based on Issue#10 , we need to change the incoming schema from DME to NCMP.
- A single subscription contains multiple predicates
- Predicates should be an array of Predicates ( currently a single instance )
- Each predicate contains an array of targets ( cmhandles) - as is.
- Each predicate contains a single datastore (mandatory)
- datastore-xpath-filter should become an array of
- xpath-filters (instead of pipe separated single string)
Performance considerations
...
- DMI record could reach in millions of instances
- In memory solution (ie hazelcast) can handle 10s - 100s of Megabytes (add some sample calc)
- still need persistence if we don't have enough intsancesinstances
- use many small messages reduce need for amalgamation
- amalgamated string-based solution....
...