Remote Actors

[pitr-ch]

Starting issue for discussion, cc @jdantonio @lucasallan.

I am thinking about following:

• to have an actor which would represent a bridge to other process
• as you've mentioned, with plug-able transport layer (usual adapter pattern I guess)
• RemoteReference implementation which would represent actors in different process, it would be created by bridge-actor and route the messages back there
• any normal Reference going through bridge would be translated to RemoteReference so it would allow for transparent communication no matter in which process the actor actually is.

What are you thoughts?

[lucasallan]

I have been thinking a lot about it and @jdantonio and I discussed numerous implementations. The last one we talked about was exactly how you describe:

server = DrbActorServer.new(Counter, :first, 5)
client = DrbActorClient.new(:first)
ref1 = client.tell( 1)
ref2 = client << 1

I don't like the idea of RemoteReference and Reference, I think we should have only Reference and a way to verify if it's remote or not.

ref1.remote?
=> true

Of course, we could have RemoteReference behind the scenes, but it won't be something that we should expose to the uses.

thoughts?

[pitr-ch]

I did not mention that RemoteReference would have same and complete API as Reference. It would be only different implementation of Reference interface. Both implementations would be interchangeable. I am afraid that having only one class for local and remote actors could make it unnecessarily complicated breaking single responsibility principle.

Is it what you disliked? Or is it something else?

Let me share example for the new actor implementation.

# PROCESS a
# Skipping the implementation of bridge, it connects to other process, 
# allows retrieval of actors on the other side. 
# Actors need to register first with the bridge
bridge = Bridge.spawn :a, DrbAdapter.new

Concurrent::Actor::Utils::AdHoc.spawn :loggers do
  # a file logger
  file = Concurrent::Actor::Utils::AdHoc.spawn :file do
    -> m { write_message_to_file }
  end

  # a stdout logger
  stdout = Concurrent::Actor::Utils::AdHoc.spawn :stdout do
    -> m { puts m }
  end

  bridge << :register # loggers can be now retrieved in other processes from bridge

  # return the loggers if somebody asks
  -> m do
    case m
    when :file
      file
    when :stdout
      stdout
    else
      pass
    end
  end
end

# PROCESS b
bridge = Bridge.spawn :b, DrbAdapter.new # leads to process a

# retrieve :loggers actor from bridge
loggers = bridge.ask! [:get, :loggers]
# => #<Concurrent::Actor::RemoteReference /loggers (Concurrent::Actor::Utils::AdHoc) bridge: b->a>
stdout = loggers.ask! :stdout
# => #<Concurrent::Actor::RemoteReference /loggers/stdout (Concurrent::Actor::Utils::AdHoc) bridge b->a>
stdout << 'error message'

# PROCESS a
# prints 'error message'

[lucasallan]

As long as we have the same API and they're interchangeable then I'm completely fine.

[jdantonio]

👍

Defining a single interface for actor references then implementing local and remote actors as different classes, both implementing the same interface, is what we had been considering. It's very similar to how both Erlang and Akka work.

[pitr-ch]

Adding implementation notes (based on discussion with @iNecas):

• Bridge connects only two processes using transport adapter.
• Adapter needs to implement only communication between two processes.
• There should be MultiBridge representing connection to whole application (many processes).
• RemoteReference going through another Bridge should keep the information how to route the message back, MultiBridge (if present) should fix it to use shortest path.

[lucasallan]

I was wondering since there is more than one dev working in this feature then would be good if we could split the work into tasks. Thoughts? @pitr-ch @jdantonio

[pitr-ch]

sorry for not being responsive lately, I've dislocated my left elbow badly, and I won't be able to write with my left hand for some time.

[schmurfy]

What is the status on this ?

remote actors is something I played with on celluloid and I am really interested in it especially since in concurrent-ruby I won't have to fight with the core since this will be a "legit" feature ^^

[lucasallan]

I'm currently building it (it's going really slow) but hopefully we will have the first implementation (not first release) in a couple months.

[schmurfy]

can I help ?:)

[pitr-ch]

@schmurfy, @lucasallan I would suggest to schedule a Hangout call so we can share our ideas and divide the work. I can also help with filling remaining unknowns about the Actor implementation since the documentation is scarce.

We could also create an branch (e.q. remote-actors) in this repo and collaborate there. If you agree, @lucasallan: could you create the branch and push there what you have already.

[schmurfy]

that's fine for me but I think that discussing here as other advantages like allowing anyone to jump in the conversation if they have any inputs :)

[lucasallan]

@pitr-ch Sounds great. I'll do it over the weekend.

[Papipo]

Is there a branch anywhere that I can help testing?

[lucasallan]

@Papipo We had all the code in a branch but then we replaced our actors implementation and this branch is outdated. However I have a bunch of scripts that I was using to adapt that implementation to our new actors. I'll push to a branch as soon as possible.

@pitr-ch I saw you added the label in progress, are you working on this thing?

[pitr-ch]

@lucasallan no, but this is in-progress generally so I've marked it.

[chrisseaton]

Closing due to extreme age.