hseeberger
commented
6 years ago Good thoughts! This will become a hell of a rewrite ;-)
BTW, backwards compatibility is not required, because we're still in 0.x land. Let's strive for optimal simplicity instead of adding complexity.
nick-nachos
The Constructr supervisor actor has a logic according to which:
About the first point, it seems redundant and restrictive at the same time to take that decision at the Constructr level:
MemberRemovedis an event that can be easily handled by the user-space (as it is akka public API), and there may be multiple cases (like our own) that the actor-system must resume operations even after leaving the cluster. Generally, shutting down the actor-system just seems to be out of the scope of Constructr as an extension.About the second point, for reasons similar to the above, what would seem more appropriate would be for Constructr to notify the user-space about its terminated state, and let it decide how to handle it (e.g. continue operation without clustering, or shutdown but perform some sort of cleanup first, etc)
The suggested approach here would be to propagate the failure related decision making to the user-space by elevating the
ConstructrExtensionclass; its functionality can be extended so that consumers may register event handlers for Constructr failure, in the same fashion as the akka "native" extensions (e.g. the 'registerOn...handlers of theCluster` extension).If backwards compatibility is required for these behaviors (i.e. terminate actor system on failures), we can add some configuration setting that will switch them on/off.
Also, given that the
ConstructrExtensionwill be used to provide new functionality, it will be also a good chance to make it abide by the latest akka extension interface, as per akka 2.5.0 theExtensionKeyclass has been deprecated. This will have the extra benefit of course that theConstructrExtensionwill be initializable both from configuration and source code as well.