...
| # | 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 (1h /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 |