References
- CPS-2000Getting issue details... STATUS
Issues & Decisions
# | Issue | Notes | Decision |
---|---|---|---|
1 | Preferred Alternative | ||
Integration Test First |
Solution Proposal
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 slower and ODL memory leak experienced
Alternative 1: New CPS-Core Kafka Message without confirmation
Notes
- LCM event should; be processed within milliseconds
- CPS-Core needs (new) infrastructure to produce (and Consume) Kafka Cloud Events
- Caffeine cache has an expiry (10mins) So NOT all models are cached all the time
- 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 )
- Delete-use case need to clear cache (for all instances) as well
Pro | Con | |
---|---|---|
1 | Update CPS-Core to produce and consume Kafka messages | |
2 | More Kafka messages (new interface) | |
3 | No unnecessary validation | |
4 | Upgrade itself not delayed |
Alternative 2: Clear Cache upon validation error
- 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 )
Pro | Con | |
---|---|---|
1 | 10 minutes window where additional validation might occur | |
2 | fails-safe wil cover all scenarios | |
3 | NO new message/interface |
Alternative 3: (existing) Kafka Message with (new) Kafka Confirmation
Not viable without knowing how many instances need to form ie need Hazelcast Cache
Pro | Con | |
---|---|---|
1 | ||
2 |
Alternative 4: (existing) Kafka Message with (new) Hazelcast Cache (semaphore)
Confirmation
Pro | Con | |
---|---|---|
1 | ||
2 |
Alternative 5: (existing) Polling (status watchdog) with (new) confirmation
Not viable because upgrades can be completed well withing polling time
Pro | Con | |
---|---|---|
1 | ||
2 |
Alternative 6: Add version info the cache-key
Pro | Con | |
---|---|---|
1 | NCMP specific solution? | |
2 | Version infor NOT readily avaialble (many impacts) |