...
| Jira | ||||||
|---|---|---|---|---|---|---|
|
Assumptions
| Assumption | Notes | Sign-off | |
|---|---|---|---|
| 1 | Solution should be CPS-Core based not just in NCMP | Caffeine Cache is a CPS-Core solution Upgrade is also possible without NCMP |
Issues & Decisions
| # | Issue | Notes | Decision | |
|---|---|---|---|---|
| 1 | Preferred Alternative | CPS Team prefers Alternative 2 | ||
| 2 | Integration Test First |
Solution
...
Proposals
Assumption
- during Upgrade two CM Handle LCM notifications are sent: 1) READY→LOCKED (for upgrade). 2) LOCKED → READY
- LCM events should be processed within Milliseconds
Alternative 0: Remove existing cache
- tried but mush much slower and ODL memory leak experienced
...
- Worst case scenario: an update (with newly modelled data) happens before cache expiry. Update gets reject (fails validation)
- mitigation: Invalidate cache upon validation error and try again (consider this as an extension alternative 2 once)
| Pro | Con | |
|---|---|---|
| 1 | 10 minutes window where additional validation might occur | |
| 2 | fails-safe wil cover all scenarios | |
| 3 | NO new message/interface | |
| 4 | Simplest solution | |
| 5 | Upgrade itself not delayed | |
| 6 | Real validation errors will always tried twice and perform relatively slowly |
Alternative 3: (existing) Kafka Message with (new) Kafka Confirmation
Not viable without knowing how many instances need to form ie need Hazelcast Cache
...
...
Alternative 4:
...
New COS-Core Kafka Message with (new) Hazelcast Cache (semaphore)
...
Confirmation
...
Just an extension of Alternative 1 which is not the preferred option
...
Alternative 5: (existing) Polling (status watchdog) with (new) confirmation
Not viable because upgrades can be completed well withing polling time
...
Alternative 6: Add version info the cache-key
| Pro | Con | |
|---|---|---|
| 1 | No issue with non-distributed cache | |
| 2 | NCMP specific solution? | |
| 23 | Version infor info NOT readily avaialble availably (many impacts) |