Skip to content

Conversation

@drexin
Copy link
Member

@drexin drexin commented Sep 3, 2019

Motivation:

Avoid storing clusterEvents on ActorSystem and also re-creating ClusterControl every time it's being used.

Result:

public var cluster: ClusterControl {
guard self.settings.cluster.enabled else {
fatalError("Tried to access cluster control, but clustering is not enabled.")
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems a bit too aggressive 🤔
Main thing is that we don't have the ref we can't issue the commands; though could we not direct them to dead letters then or log a warning that cluster is disabled?

A bit iffy on crashing hard on this, hm... 🤔 Even a "single node cluster" sometimes is a thing, without binding, so one might want to kick off things automagically assuming we are "up" when we are not bound to any port, but want to test our other logic about lifecycle etc 🤔

if let servant = self._servants[pid] {
self.system.cluster._shell.tell(.command(.downCommand(servant.node.node)))
self.system.cluster.down(node: servant.node.node)
self._servants.removeValue(forKey: pid)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Member

@ktoso ktoso left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general great, though had some doubts -- inline :)

public func shutdown() {
self.log.log(level: .debug, "SHUTTING DOWN ACTOR SYSTEM [\(self.name)]. All actors will be stopped.", file: #file, function: #function, line: #line)
if self.settings.cluster.enabled {
if let cluster = self._cluster {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good to move from the settings check to this style 👍

// initialized during startup
internal var _cluster: ClusterShell?
internal var _clusterEvents: EventStream<ClusterEvent>?
internal var _clusterControl: ClusterControl?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice; I wonder if we need to store the _cluster as well though?
All usage I guess would rather be though _control? we can always _clusterControl._shell?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Thinking to have as little fields for the same thing as we can for the core actor system; we'd have exactly one way to access the shell then etc)

public var cluster: ClusterControl {
guard self.settings.cluster.enabled else {
fatalError("Tried to access cluster control, but clustering is not enabled.")
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks :)

@ktoso
Copy link
Member

ktoso commented Sep 12, 2019

It's a good improvement, so let's keep moving :)

The comment about removing _cluster from system in https://github.com/apple/swift-distributed-actors/pull/89/files#r320593185 still stands, and maters for receptionist where it now does: let remoteControls = context.system._cluster!.associationRemoteControls // FIXME: should not be needed and use cluster members instead but we can do this in follow up?

@ktoso ktoso merged commit 5d37a1f into master Sep 12, 2019
@ktoso ktoso deleted the wip-74 branch September 12, 2019 05:12
@ktoso
Copy link
Member

ktoso commented Sep 12, 2019

Opened #111 for discussion / followup

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Maybe create ClusterControl in ActorSystem directly?

3 participants