...
| Error Scenario | Expected behavior | Sign-off | |
|---|---|---|---|
| 1 | DMI Down | rejected | |
| 2 | DMI Not responding withing 30 sec | pending | |
| 3 | create for non-existing cm handle id | rejected | |
| 4 | delete for non-existing cm handle id | (silently?) ignore | |
| 5 | any operation on non-existing xpath | ignore? (no or minimal validation, see issue #5) | |
| 6 | delete for non existing name/client-id | TBD, should be handle in 'basic' solution | |
| 7 | delete for no existing cm-handle idTBD | ignore? (no or minimal validation, see issue #5) | |
| 8 | error upon error | An error scenario on a second subscription for the same cm-handle/xpath as a previous subscription which did not complete successfully (yet) to be discussed, see tabel below |
...
| # | 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:
| ||
| 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? | ||
| 3 | Should NCMP support re-homing, moving of a CM Handle from one DMI to another? | assume only trough delete & create | ||
| 4 | CM Handle Delete: Should DMI or Clients be sent a subscription update (assume no) | do NOT delete dmi-subscription entry until owning subscription is deleted (just ignore upon future delete if cm handle is gone altogether) | ||
| 5 | Validation of xpath | options order of implement and also performance cost!
| ||
| 6 | can DMI plugin 'reject' a subscription create (for a given cm-handelhandle-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') | |
| 7 | implementation question: should 'rejected' DMI-subscriptions be stored | I would think not | ||
| 8 | Dimensioning of DB depends on #cm handles, | #subscrptions#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 | |
| 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! | ||
| 10 | can each CM-Handled have different set of xpaths(s) per subscription | teh 'basic' solution only supports a common set of daatstore/xpaths (filter) |
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 |
...
| Existing Subscription A-10 | Client Create Subscription B-35 52 Request | DMI Create Request | Data Model Before | Data Model After | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | CH-1, [ /p/c1, /p/c2 ] | CH-1, [ /p/c1 ] | None |
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2 | CH-1, [ /p/c1, p/c2 ] | CH-1, [ /p/c2, /p/c3 ] | CH-1, [ /p/c3 ] |
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 3 | CH-1, [ /p/c1] CH-2, [ /p/c1] | CH-2, [ /p/c1] CH-3, [ /p/c1] | CH-3, [ /p/c1] |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 4 | CH-1, [ /p/c1] | CH-1, [ /p/c1/gc1 ] | CH-1, [ /p/c1/gc1 ] (see issue #1) |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
Delete Combinations
| NCMP Existing A | NCMP Existing B | Client Delete A Request | DMI Delete Request | |
|---|---|---|---|---|
| 1 | CH-1, [ /p/c1, p/c2 ] | CH-1, [ /p/c1 ] | CH-1, [ /p/c1, p/c2 ] | 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] CH-2, [ /p/c1] | CH-1, [ /p/c1] |
| 3 | CH-1, [ /p/c1] | CH-1, [ /p/c1] CH-2, [ /p/c1] | CH-1, [ /p/c1] | None |
...
| Previous Interaction | Current Interaction | Expectation | Notes | |
|---|---|---|---|---|
| 1 | any operation on rejected for non-existing cm-handle | operation for same non-existing cm-handle | listed in 'rejected' immediately | behavior as normal |
| 2 | create operation rejected by DMI | create for same cm-handle/xpath | try again ?! | |
| 3 | create pending | create for same cm-handle/xpath | TBD send again or just remain pending?! | |
| 4 | create pending | delete for same cm-handle/xpath | ||
| 5 | delete pending | delete for same cm-handle/xpath | also being considered for 'basic' delete | |
| 6 | delete pending | create for same cm-handle/xpath | also being considered for 'basic' delete | |
| 7 |
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 intsances
- use many small messages reduce need for amalgamation
- amalgamated string-based solution....
Proposed JIRAs
| Priority | Component | Description | JIRA | Estimates |
|---|---|---|---|---|
| 1 | ||||
| 2 | ||||
| 3 | ||||
| 4 | ||||
| 5 | ||||
| 6 | ||||
| 7 | ||||
| 8 |
...