cds-access-client's AbstractClientActor inherits from akka.persistence.AbstractPersistentActor. It uses akka-persistence to store the ClientIdentifier it is about to start using.
This is quite unnecessary and can lead to operational errors where the user deletes all of Akka persistence on a single node, only to be faced with a cds-access-client-driven failure to establish connect to the backend, as the backend state (replicated) remembers last the ClientIdentifier, whereas cds-access-client does not.
Add a migration path, where AbstractClientActor would persist the ClientIdentifier in a properties file, stored in state/org.opendaylight.controller.cluster.access.client-<member-name>-<client-type>.properties:
Generation and reading of this file should be aligned with akka-persistence lifecycle:
this file, if present, should be taken as the initial state
then if a ClientIdentifier is recovered from akka-persistence, the two should be compared and a suitable winner should be picked
then the file should be updated (using atomic operations)
then a new PersistenceTombstone object should be stored in akka-persistence instead of the usual ClientIdentifier
The end result is that each actor will automatically migrate to the properties file and will retain the record of doing so via PersistenceTombstone – which itself has no semantic meaning.
cds-access-client's AbstractClientActor inherits from akka.persistence.AbstractPersistentActor. It uses akka-persistence to store the ClientIdentifier it is about to start using.
This is quite unnecessary and can lead to operational errors where the user deletes all of Akka persistence on a single node, only to be faced with a cds-access-client-driven failure to establish connect to the backend, as the backend state (replicated) remembers last the ClientIdentifier, whereas cds-access-client does not.
Add a migration path, where AbstractClientActor would persist the ClientIdentifier in a properties file, stored in state/org.opendaylight.controller.cluster.access.client-<member-name>-<client-type>.properties:
Generation and reading of this file should be aligned with akka-persistence lifecycle:
this file, if present, should be taken as the initial state
then if a ClientIdentifier is recovered from akka-persistence, the two should be compared and a suitable winner should be picked
then the file should be updated (using atomic operations)
then a new PersistenceTombstone object should be stored in akka-persistence instead of the usual ClientIdentifier
The end result is that each actor will automatically migrate to the properties file and will retain the record of doing so via PersistenceTombstone – which itself has no semantic meaning.