CPS-2000 Schema object cache not distributed.
- Toine Siebelink
- 1 References
- 2 Assumptions
- 3 Issues & Decisions
- 4 Solution Proposals
- 4.1 Alternative 0: Remove existing cache
- 4.2 Alternative 1: New CPS-Core Kafka Message without confirmation
- 4.3 Alternative 2 (chosen): Clear Cache upon validation error
- 4.4 Alternative 3: (existing) Kafka Message with (new) Kafka Confirmation
- 4.5 Alternative 4: New COS-Core Kafka Message with (new) Hazelcast Cache (semaphore) Confirmation
- 4.6 Alternative 5: (existing) Polling (status watchdog) with (new) confirmation
- 4.7 Alternative 6: Add version info the cache-key
References
https://lf-onap.atlassian.net/browse/CPS-2000
Assumptions
Assumption | Notes | ||
|---|---|---|---|
| 1 | 1 | Solution should be CPS-Core based not just in NCMP | Caffeine Cache is a CPS-Core solution |
| 2 | 2 | Upgrades are backward compatible |
|
Issues & Decisions
Issue | Notes | Decision | ||
|---|---|---|---|---|
| 1 | 1 | Preferred Alternative | CPS Team prefers Alternative 2 | Jan 10, 2024 Team and stakeholders agreed on Alternative 2 |
| 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 (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 (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) |