References
- CPS-2000Getting issue details... STATUS
Issues & Decisions
# | Issue | Notes | Decision |
---|---|---|---|
1 | Preferred Alternative |
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: (existing) Kafka Message without confirmation
Notes
- LCM event should; be processed within milliseconds
- 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 1a )
Pro | Con | |
---|---|---|
1 | ||
2 |
Alternative 2: (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 3: (existing) Kafka Message with (new) Hazelcast Cache (semaphore)
Confirmation
Pro | Con | |
---|---|---|
1 | ||
2 |
Alternative 4: (existing) Polling (status watchdog) with (new) confirmation
Not viable because upgrades can be completed well withing polling time
Pro | Con | |
---|---|---|
1 | ||
2 |
Alternative 5: Add version info the cache-key
Pro | Con | |
---|---|---|
1 | ||
2 |