References
CPS-2000 - Getting issue details... STATUS
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
Alternative 0: Remove existing cache
- tried but much 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 (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? | |
| 3 | Version info NOT readily availably (many impacts) |