CPS-1015 - Getting issue details... STATUS
Use Case
Using a Spring distributed cache to prevent watchdogs working on the same ADVISED cm handles during model sync, since we don't have an in-between state from ADVISED to READY.
Eg:
Watchdog A wakes up, works on Cm-Handle-1 which has state of ADVISED and stores this in memory
Watchdog B wakes up, attempts to work on Cm-Handle-1, which still has a state of ADVISED, but is being worked on by Watchdog A, so this then moves on to Cm-Handle-2
Overview
| Sr No. | Type | Example | Feature |
|---|---|---|---|
| 1 | Embedded | Caffeine , Ehcache , Guava Library for Cache etc | Data is in memory. Not distributed among multiple instances. |
| 2 | Embedded Distributed | Hazelcast | Data is in memory and distributed across multiple instances.(Scalability of cache goes hand in hand with app instances) |
| 3 | Client-Server Topology | Hazelcast , Redis , Memcached , Coherence | Separate cache cluster can be managed. Client is our application and Server is the cache cluster. |
| 4 | Cloud (Client-Server) | Redis on AWS etc. | Cluster managed by leading cloud provider |
Issues and decisions
# | Questions/Open Issues | Notes | Decision/Answer |
|---|---|---|---|
| 1 | #2 Embedded Distributed. | We will be storing small amount of data( just the cmHandle id's ) and we don't need persistence of the data (once the application restarts the data will be gone) | Start with a POC on #2 , also check any recommendation from ONAP. |