Some ideas

[qazwsxedckll]

1. Using type+name as the identity rather than name only.

2. Send message without knowing if the actor is local or not.

	addr, pid, err := s.actorSystem.ActorOf(ctx, accountID)
	// handle the error
	if err != nil {
		return nil, connect.NewError(connect.CodeInternal, err)
	}

	var message proto.Message
	command := &samplepb.GetAccount{
		AccountId: accountID,
	}

	if pid != nil {
		s.logger.Info("actor is found locally...")
		message, err = actors.Ask(ctx, pid, command, time.Second)
		if err != nil {
			return nil, connect.NewError(connect.CodeInternal, err)
		}
	}

	if pid == nil {
		s.logger.Info("actor is not found locally...")
		reply, err := actors.RemoteAsk(ctx, addr, command)
		if err != nil {
			return nil, connect.NewError(connect.CodeInternal, err)
		}

		message, _ = reply.UnmarshalNew()
	}

3. Smarter spawn strategy, rather than spawn locally or on designated node and then rebalance. Btw, I do not see any rebalancing codes.

4. Maybe add actor client so that services can be moved to other programs and the client can know where the actor locates before sending messages.

5. Actors with the same subset of message types should be considered as the same type.
   For example, if ParentActor can handle MessageA and ChildActor can handle MessageA and MessageB. An instance of ChildActor is considered as ParentActor. (Something like the golang interface, do not know if it is possible or not)

[Tochemey]

1. Using type+name as the identity rather than name only.

Yeah we can add the actor type to the identity. However actor ID are determined by their path in the actor system. Bear in mind actors cannot live without a system.

2. Send message without knowing if the actor is local or not.

	addr, pid, err := s.actorSystem.ActorOf(ctx, accountID)
	// handle the error
	if err != nil {
		return nil, connect.NewError(connect.CodeInternal, err)
	}

	var message proto.Message
	command := &samplepb.GetAccount{
		AccountId: accountID,
	}

	if pid != nil {
		s.logger.Info("actor is found locally...")
		message, err = actors.Ask(ctx, pid, command, time.Second)
		if err != nil {
			return nil, connect.NewError(connect.CodeInternal, err)
		}
	}

	if pid == nil {
		s.logger.Info("actor is not found locally...")
		reply, err := actors.RemoteAsk(ctx, addr, command)
		if err != nil {
			return nil, connect.NewError(connect.CodeInternal, err)
		}

		message, _ = reply.UnmarshalNew()
	}

Agreed we can add some utilities method to abstract this kind of code.

3. Smarter spawn strategy, rather than spawn locally or on designated node and then rebalance. Btw, I do not see any rebalancing codes.

Actors are spawned locally and redistributed when cluster mode is activated (https://github.com/Tochemey/goakt/blob/main/actors/actor_system.go#L1285). One can also create actor on remote machine within the same actor system. Can you please elaborate on the smart spawn strategy?

4. Maybe add actor client so that services can be moved to other programs and the client can know where the actor locates before sending messages.

One can use the RemoteLookup API to get the location of an actor before sending a message. Please is that what you are referring to?

5. Actors with the same subset of message types should be considered as the same type.
   For example, if ParentActor can handle MessageA and ChildActor can handle MessageA and MessageB. An instance of ChildActor is considered as ParentActor. (Something like the golang interface, do not know if it is possible or not)

[Tochemey]

@qazwsxedckll At the moment like stated in this release actors of the left node in a cluster mode are redistributed to the remaining of the cluster as long as the cluster is healthy. The current implementation will need some enhancement. Basically in a cluster mode

• each node has local copy of the state and here of the other nodes in the cluster.
• when a given node leaves the cluster the cluster coordinator distribute the left node actors to the rest of the cluster by recreating them using this code.

is it what you were looking for when talking about rebalancing?

[qazwsxedckll]

@Tochemey But rebalancing only happens when the topology changes right? I think it is better to spawn actors on the correct node, the one with least count for now, without any elaborate code. If some how all requests are going to one node, I think actors are piling up now.

[Tochemey]

@qazwsxedckll Yes rebalancing only happens when the topology changes. Regarding the creation of actor, at the moment one needs to know the node where the actor is going to live before creating.Spawn only create actor locally while RemoteSpawn create an actor remotely. At the moment the only client code to create actor is the RemoteSpawn. This is the current implementation. I hope this will help you elaborate on the suggestion you are making.

Yeah we can introduce a smart way of creating via a cluster client. That will only be available when running in a cluster. is that what you advocating for?

[Tochemey]

@qazwsxedckll I think this is what you are suggesting:

When cluster mode is activated, the creation of actor should use some sort of consistent hashing algorithm to locate the appropriate node where the actor should live by also taking into consideration node loads without overloading a particular node.

[qazwsxedckll]

@Tochemey Yes, even round-robin is way better than choose node manually. It is a little hard for me to make my point clearer, English is not my first language. Sorry for that.

[Tochemey]

@qazwsxedckll Thanks for the suggestion and no worries about English. I got you. I will create an issue and see what I can come up with. Yes, I agree that in cluster mode actor creation and lookup should be seamless.

[qazwsxedckll]

@Tochemey It is wired that RemoteLookupReqest needs host and port. What I mean is the actor client can ask any nodes where the actor is located and then it can send message to the returned address.

For now, the api services are actually bundled with actor systems, which is not a serious problem. The issue here is that without some rpc apis. It is not possible to call actors directly.

[Tochemey]

@qazwsxedckll RemoteLookup is for remoting which does not take into account clustering and ones needs to know the node he/she is querying. What you are suggesting is a kind of cluster lookup.

[Tochemey]

For now, the api services are actually bundled with actor systems, which is not a serious problem

Can you please explain this? I have this kind of setup in my examples though. Is that what you are referring to or it is something else in the current design?

[qazwsxedckll]

This is what I am referring to. If you move the services to independent programs, they are not accessible to ActorSystem.

[Tochemey]

@qazwsxedckll I will look into the cluster client. Thanks for bringing it out.

[Tochemey]

@qazwsxedckll By the way this method addr, pid, err := s.actorSystem.ActorOf(ctx, accountID) already does the smart lookup of an actor when cluster mode is enabled. It returns both the PID and the remoting address of the actor. This allows the implementor to either check whether it is local actor not.

[Tochemey]

@qazwsxedckll I have created an issue here to look into the cluster client feature #370

[Tochemey]

@qazwsxedckll the client implementation is done and merged. I will do some QA and release it in the coming days. #371

Please feel free to add more balancers 😏