WIP - Cluster bootstrap remoting probe method #546
Conversation
|
Any thoughts on the points raised above? Should this go the full way and decouple cluster bootstrap from Akka management HTTP? Should the spray-json serializers used by remoting be replaced with protobuf serializers? Also, currently the probing method has two hard coded options and is not pluggable, but it could be made such that we extract an interface that the two options can implement, and then allow other probing methods to be introduced. Not sure if that's a good idea or not, it would increase the effective public API and required semantics, whereas if we keep it as two hardcoded possibilities then that stuff can all stay internal which allows us to modify it as we see fit going forward. |
There was a problem hiding this comment.
Thanks for taking a first stab. I think in the long run we want to do this change but currently the Akka team would like to wait with this some more because we are busy with other things and it would be good to let akka-management be stable for a while before doing more substantial changes like this.
Regarding your questions:
Should this go the full way and decouple cluster bootstrap from Akka management HTTP?
I think we should go even further and remove the HTTP probing unless we have a good reason for supporting both. We would do change to remove complexity and that is not achieved by having two ways.
Should the spray-json serializers used by remoting be replaced with protobuf serializers?
Yes, less dependencies.
| @@ -99,9 +99,14 @@ akka.management { | |||
| # Configured how we communicate with the contact point once it is discovered | |||
| contact-point { | |||
|
|
|||
| # The probe method. Valid values are akka-management and remoting. If akka-management, will use akka-management | |||
| # HTTP interface to discover seed nodes. If remoting, will use Akka remoting to discover seed nodes. | |||
| probe-method = "akka-management" | |||
There was a problem hiding this comment.
why do we want to support both methods?
There was a problem hiding this comment.
You won't be able to do a rolling upgrade to the new method if you don't support both concurrently.
| .orElse(cluster.selfAddress.port) | ||
| .getOrElse(throw new IllegalArgumentException("Cannot infer port for contact point")) | ||
| val address = cluster.selfAddress.copy(host = Some(contactPoint.host), port = Some(targetPort)) | ||
| (self.path.parent.parent / RemotingContactPoint.RemotingContactPointActorName).toStringWithAddress(address) |
There was a problem hiding this comment.
might be better with RootActorPath:
RootActorPath(address) / "system" / RemotingContactPoint.RemotingContactPointActorName
Some initial work on #453. This has been done in an effort to try and slim down cluster bootstrap, both in terms of complexity and the amount of resources it uses.
This works, but there are a few things to think about.
One nice thing is that remoting doesn't need the same hack that is used to discover the Akka management HTTP bind address.