...
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Assumptions
| Assumption | Notes | |
|---|---|---|
| 1 | Solution should be CPS-Core based not just in NCMP | Caffeine Cache is a CPS-Core solution Upgrade is also possible without NCMP |
| 2 | Upgrades are backward compatible |
Issues & Decisions
| # | Issue | Notes | Decision | |
|---|---|---|---|---|
| 1 | Preferred Alternative |
...
| CPS Team prefers Alternative 2 | Team and stakeholders agreed on Alternative 2 | ||
| 2 | Integration or jUnit Test First | Agreed but only possible using Unit Test (stil using real cache etc.) |
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 (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 )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 (chosen): 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) |