Closed ljacomet closed 8 years ago
As discussed in planning meeting, as part of this issue primarily we will focus on following points :- -- Configuration -- creating ClusteredCacheMananger, connecting it to the server side counterpart of it. -- Focusing on Lifecycle of ClusteredCacheManager and handling of failure scenarios.
After the discussions in dev meeting, we came to an consensus to add ARC config to the scope of this task. This will help in setting up the ground even for the unclustered cases.
Somewhat reducing the scope of this issue. Let's focus on the ServerSideCacheManagerEntity
from a Voltron perspective for now... that still requires addressing the concerns around "Voltron Storage API" though, but "only" for the CacheManager
's metadata, i.e. not key-value mappings.
This also leaves all client side (and Ehcache user) APIs out of scope for now (or at least they don't need to be defined end-to-end, sketches to drive the server-side entity's API should suffice). We still need to nail the server's storage config API though, as that will be user facing.
Waiting on Coordinator entity to be read in Terracotta-OSS/terracotta-platform#3 to finish the life cycle aspect of the this issue
The ClusteredCacheManagerEntityManager
needs to account for "taking over" a nomination from another client... Like in the case where it is supposed to create then actual ClusteredCacheManagerEntity
... See terracotta-oss/terracotta-platform#15
Obsolete, now covered by the issues under the BF-4487 milestone.