Details
-
Bug
-
Status: Resolved
-
Resolution: Done
-
Helium
-
None
-
None
-
Operating System: All
Platform: All
-
2284
Description
This is specialization of https://bugs.opendaylight.org/show_bug.cgi?id=1821 to context similar to https://bugs.opendaylight.org/show_bug.cgi?id=2283
Yes, applications should not write to a shard lacking a Leader, but installation of a karaf feature causes that, and Leaderless state is probable just at the time when clustering feature is being installed.
Basically, perhaps only a configurable transaction timeout is needed to make sure shard finds its Leader quicker.
It is also possible that the more responsible component should be config subsystem, detecting this state and re-trying for a (configurable) time.
Current workaround is to always verify clustering feature is fully ready before installing more features.
A log attached, showing what happens when instance (of 3 node cluster) starts isolated and features are slowly being installed.
Attachments
Issue Links
- is blocked by
-
CONTROLLER-890 Clustering: Handle shard initialization failures in DistributedDataStore#registerChangeListener
- Resolved