Server-initiated (server-side managed) Remote Actors implemented

[Jonas Bonér]

Hi guys.

Yesterday I implemented server-initiated remote actors. This is a complement to the current client-initiated remote actors. 

In the client-initiated remote actors it is the client that creates the remote actor and "moves it" to the server.

In the server-initiated remote actors it is the server that creates the remote actor and the client can ask for a handle to this actor.

The good thing about this model is that: 

1. There is no need to have the remote actor code on the client nodes, but only on the server node.

2. It gives better security and control

The bad things are:

1. Supervision is not done from client-server but only on the server. E.g. the client is not notified if the remote actor dies and can not supervise it, but it is managed transparently from the client on the server node. Some might say this is a plus as well, but that depends on your use-case

2. The client handle to the remote actor is a dummy actor, it does of the same type as the remote actor. So the RPC is less transparent compared to client-initiated remote actors.

The API is really simple. 2 methods only.

1. Server-side

    // register the actor as remote service

    server.register("hello-service", new HelloWorldActor)

2. Client-side

    // get the handle to the remote actor

    val actor = RemoteClient.actorFor("hello-service", "localhost", 9999)

    // use it as normal

    val result = actor !! "Hello"

Here is a complete running sample (http://github.com/jboner/akka/blob/master/akka-core/src/test/scala/ServerInitiatedRemoteActorSample.scala).

class HelloWorldActor extends Actor {

  start

  def receive = {

    case "Hello" => reply("World")

  }

}

object ServerInitiatedRemoteActorServer {

  def run = {

    val server = new RemoteServer()

    server.start("localhost", 9999)

    server.register("hello-service", new HelloWorldActor)

  }

  def main(args: Array[String]) = run

}

object ServerInitiatedRemoteActorClient extends Logging {

  

  def run = {

    val actor = RemoteClient.actorFor("hello-service", "localhost", 9999)

    val result = actor !! "Hello"

    log.info("Result from Remote Actor: %s", result)

  }

  def main(args: Array[String]) = run

}

Let me know what you think. 

--
Jonas Bonér

twitter: @jboner
blog:    http://jonasboner.com
work:   http://scalablesolutions.se
code:   http://github.com/jboner
code:   http://akkasource.org
also:    http://letitcrash.com

[christophe...@gmail.com]

Sweet!

I'll test this out when I have "trunk" set up rather than the the 0.6
release.

> Here is a complete running sample (http://github.com/jboner/akka/blob/master/akka-core/src/test/scala/Se...

[Viktor Klang]

This is _really_ cool!
 

--
Jonas Bonér

twitter: @jboner
blog:    http://jonasboner.com
work:   http://scalablesolutions.se
code:   http://github.com/jboner
code:   http://akkasource.org
also:    http://letitcrash.com

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang

[Bobby Boyd]

@Christopher did you get anywhere with this? I'm getting ready to try to do the same thing.

@Everyone else. So what's the model here? My thoughts are to have one or more MINA servers that accept client connections (or would Netty be better for this?) and then allocate a remote actor per client. I'm not sure if or why this would have to be client-initiated or server-initiated.

Basically the game client and the MINA server would speak a custom game protocol, then the MINA server would translate these game messages to messages to send to the remote actor. The point would be to take advantage of Akka's supervisor hierarchy for failure handling as well as clustering for wide scalability. Is this a reasonable approach?

Best,

Robert Boyd
Twitter: @rboyd

[Jonas Bonér]

Hi Bobby.

Thanks for your interest in Akka.

On 19 March 2010 19:16, Bobby Boyd <rb...@telematter.com> wrote:
>
> @Christopher did you get anywhere with this?  I'm getting ready to try to do the same thing.
>
> @Everyone else.  So what's the model here?  My thoughts are to have one or more MINA servers that accept client connections (or would Netty be better for this?) and then allocate a remote actor per client.  I'm not sure if or why this would have to be client-initiated or server-initiated.

The simplest approach would be to create one client-initiated actor
per client. The other way would be to have one
server-initiated/managed remote actor that receives a request to
create a "local" client actor (on the server), e.g. the remote actor
works as a broker.

>
> Basically the game client and the MINA server would speak a custom game protocol, then the MINA server would translate these game messages to messages to send to the remote actor.  The point would be to take advantage of Akka's supervisor hierarchy for failure handling as well as clustering for wide scalability.  Is this a reasonable approach?

That sounds good to me.
If you need remote supervision then you have to use client-initiated
remote actors.

Hope it helps, Jonas.

[Ross McDonald]

Hi Jonas.

I finally have some time to play with this now, looks like something I can use. I am however having a little trouble with my own little use case.

I hope to create a simple server managed remote actor on one machine, just like your HelloWorldActor, then test connecting to it from another box.

I have Akka 0.8.1 on both boxes, with out of the box configuration in akka-reference.conf.

I am currently getting a:

java.nio.channels.NotYetConnectedException

Is there anything else I need to do in terms of config, other than ensuring the port is open ?

Thanks for your help,

-- Ross

> --
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

Ross McDonald
Twitter: @rossajmcd
Blog: rossputo.blogspot.com

[Jonas Bonér]

Have you started up a RemoteNode and registered the actor? Hard to
help if I can't see the code or get any more info.

--
Jonas Bonér
http://jayway.com
http://akkasource.org

[Ross McDonald]

Hi Jonas.

Good point, apologies, I raced off to a meeting and rushed that email out.

On machine 1 I have followed the following steps:

- sbt console

then in the REPL:

import se.scalablesolutions.akka.actor.Actor

class HelloWorldActor extends Actor {
start
def receive = {
case "Hello" => reply("World")
}
}

RemoteNode.start("localhost", 9999)

RemoteNode.
register("hello-service", new HelloWorldActor)



On machine 2 the following steps:

- sbt console

then in the REPL:

import se.scalablesolutions.akka.remote.RemoteClient

val actor = RemoteClient.actorFor("hello-service", "some_host", 9999)


which yields:

Remote client connection to [some_host:9999] has failed
remote: java.net.ConnectException: Connection refused

thanks

-- Ross

>>> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
>>> For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
>>

>> Ross McDonald
>> Twitter: @rossajmcd
>> Blog: rossputo.blogspot.com
>>
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Akka User List" group.
>> To post to this group, send email to akka...@googlegroups.com.

>> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
>

Ross McDonald
Twitter: @rossajmcd
Blog: rossputo.blogspot.com




--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.

[Viktor Klang]

Hi Ross,

can you try to run them on the same machine but different consoles to eliminate network config interference?

Thanks,

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang

[Ross McDonald]

Hi Viktor.

Confirmed working with two 'sbt console' REPL's on the same machine.

I will ask the network guys here again if the port is open. Is there anything else I need to configure ?

Thanks,

-- Ross

[Ross McDonald]

Hi.

I unpacked a brand new jetty, set its port to 9999 and confirmed I can telnet to it from the client machine, so the network boys have definitely allowed the port I need

-- Ross

On 19 Apr 2010, at 15:06, Viktor Klang wrote:

[Viktor Klang]

Hi Ross,

Sorry for the delay, I'll take a look at it tonight, got some chores to attend first.

Hang in there,

Cheers,

[Ross McDonald]

No worries Viktor.

As per usual thanks for helping out :-)

-- Ross

[Viktor Klang]

Hi Ross!

I can't seem to reproduce: Here are my two different sbt consoles:

===========ServerManaged=============

cala> import se.scalablesolutions.akka.remote._
import se.scalablesolutions.akka.remote._

scala> RemoteNode.start("localhost",9999)      
INF [20100419-23:30:51.307] config: AKKA_HOME is defined to [/Users/foldLeft/Documents/workspace/akka/akka], config loaded from [/Users/foldLeft/Documents/workspace/akka/akka/config/akka.conf].
INF [20100419-23:30:52.650] remote: Starting remote server at [localhost:9999]

scala> import se.scalablesolutions.akka.actor._     
import se.scalablesolutions.akka.actor._

scala> RemoteNode.register("foo", new Actor { def receive = { case "ping" => reply("pong") } } )
INF [20100419-23:32:03.724] remote: Registering server side remote actor [line6$object$$iw$$iw$$iw$$iw$$iw$$iw$$iw$$iw$$anon$1] with id [foo]
res2: Any = null

=======================================


============Client=======================

scala> import se.scalablesolutions.akka.remote._                                                
import se.scalablesolutions.akka.remote._

scala> RemoteNode.start("localhost",4444)
INF [20100419-23:35:05.645] config: AKKA_HOME is defined to [/Users/foldLeft/Documents/workspace/akka/akka], config loaded from [/Users/foldLeft/Documents/workspace/akka/akka/config/akka.conf].
INF [20100419-23:35:06.809] remote: Starting remote server at [localhost:4444]
              
scala> val a = RemoteClient.actorFor("foo","localhost",9999)
INF [20100419-23:35:34.437] remote: Starting remote client connection to [localhost:9999]
a: se.scalablesolutions.akka.actor.Actor = Actor[se.scalablesolutions.akka.remote.RemoteClient$$anon$1:1272786673563]

scala> a !! "ping"
res2: Option[Nothing] = Some(pong)



=========================================



Notice how I started the REmoteNodes on different ports since they were running on the same machine, if RemoteNode hasn't been started before RemoteNode.actorFor, it will be started on the akka.conf host/port

All tests were run against latest master.

Does any of this help?

Cheers!

[Ross McDonald]

Hi Viktor.

Thanks for looking into it. I will try to reproduce again when I get into the office. Did you use the latest git pull on master, 'sbt console' ing in from the top directory?

Thanks

-- Ross

[Viktor Klang]

On Tue, Apr 20, 2010 at 8:39 AM, Ross McDonald <ross...@gmail.com> wrote:

Hi Viktor.

Thanks for looking into it.  I will try to reproduce again when I get into the office.  Did you use the latest git pull on master, 'sbt console' ing in from the top directory?

Yes, I did a git pull and then an sbt clean, sbt compile and sbt console :-)
 

[Ross McDonald]

Hi Viktor.

I reproduced your test fine with two sbt consoles on the same machine, as expected.
I then failed to reproduce it on two different machines. The test yielded:

ERR [20100420-09:42:08.013] remote: Could not start up remote server
ERR [20100420-09:42:08.013] remote: org.jboss.netty.channel.ChannelException: Failed to bind to: /some_IP:9999
ERR [20100420-09:42:08.013] remote: at org.jboss.netty.bootstrap.ServerBootstrap.bind(ServerBootstrap.java:306)
ERR [20100420-09:42:08.013] remote: at se.scalablesolutions.akka.remote.RemoteServer.liftedTree1$1(RemoteServer.scala:177)
ERR [20100420-09:42:08.013] remote: at se.scalablesolutions.akka.remote.RemoteServer.start(RemoteServer.scala:164)
ERR [20100420-09:42:08.013] remote: at se.scalablesolutions.akka.remote.RemoteServer.start(RemoteServer.scala:161)

inline below is my modification to your test:

On 19 Apr 2010, at 22:41, Viktor Klang wrote:

> Hi Ross!
>
> I can't seem to reproduce: Here are my two different sbt consoles:
>
> ===========ServerManaged=============
>
> cala> import se.scalablesolutions.akka.remote._
> import se.scalablesolutions.akka.remote._
>
> scala> RemoteNode.start("localhost",9999)
> INF [20100419-23:30:51.307] config: AKKA_HOME is defined to [/Users/foldLeft/Documents/workspace/akka/akka], config loaded from [/Users/foldLeft/Documents/workspace/akka/akka/config/akka.conf].
> INF [20100419-23:30:52.650] remote: Starting remote server at [localhost:9999]
>
> scala> import se.scalablesolutions.akka.actor._
> import se.scalablesolutions.akka.actor._
>
> scala> RemoteNode.register("foo", new Actor { def receive = { case "ping" => reply("pong") } } )
> INF [20100419-23:32:03.724] remote: Registering server side remote actor [line6$object$$iw$$iw$$iw$$iw$$iw$$iw$$iw$$iw$$anon$1] with id [foo]
> res2: Any = null
>
> =======================================
>
>
> ============Client=======================
>
> scala> import se.scalablesolutions.akka.remote._
> import se.scalablesolutions.akka.remote._
>
> scala> RemoteNode.start("localhost",4444)

this line changed to :

RemoteNode.start("some_IP", 9999)

[Jonas Bonér]

Is "some_IP" the name of the server? It needs to be a valid IP address
or host name.

--
Jonas Bonér

work: http://jayway.com
code: http://akkasource.org
blog: http://jonasboner.com
twitter: @jboner

[Jonas Bonér]

On 20 April 2010 10:56, Jonas Bonér <jo...@jonasboner.com> wrote:
> Is "some_IP" the name of the server? It needs to be a valid IP address
> or host name.

And of course mapped correctly to the IP address in the routing table.

[Ross McDonald]

Hi Jonas.

Yes, some_IP is a valid IP address. My client machine can see it over the network.

Cheers,

-- Ross

[Jonas Bonér]

Odd. Does it work if you type in the IP instead?

[Ross McDonald]

Hi Jonas. I have been using the IP. I will try the hostname now. The only tests I have seen working have been on the same box.

-- Ross

[Ross McDonald]

Hi Jonas.

Confirmed, same problem if I use the host name as when I use the IP.

-- Ross

On 20 Apr 2010, at 10:09, Jonas Bonér wrote:

[Ross McDonald]

Hi Guys.

Sorry for the thread bump, just wondering has anyone actually run this on two different physical machines ? If so, could you walk me through the steps?

Thanks for your help, this is still a problem for me, not critical yet, but eventually I will need to spread the architecture out beyond one physical machine.

Cheers,

-- Ross

On 20 Apr 2010, at 10:09, Jonas Bonér wrote:

[Jonas Bonér]

This should of course work. It has worked fine before. I even have had attendees having lab code talking with their neighbours laptop on my training sessions.
Could be a regression.
I'll look into it tomorrow.

On 21 Apr 2010 17:53, "Ross McDonald" <ross...@gmail.com> wrote:

Hi Guys.

Sorry for the thread bump, just wondering has anyone actually run this on two different physical machines ?  If so, could you walk me through the steps?

Thanks for your help, this is still a problem for me, not critical yet, but eventually I will need to spread the architecture out beyond one physical machine.

Cheers,

 -- Ross

On 20 Apr 2010, at 10:09, Jonas Bonér wrote:

> Odd. Does it work if you type in the IP instead?
>

> On 20 April 2010 11:05, Ross McDonald <rossa...

> --

> You received this message because you are subscribed to the Google Groups "Akka User List" group.

...

[Ross McDonald]

Hi Jonas.

Thanks for looking into it, probably just me being a muppet missing some critical config or step to get it working.

Cheers,

-- Ross

Ross McDonald
Twitter: @rossajmcd
Blog: rossputo.blogspot.com

[Viktor Klang]

Hi guys,

I'd love to help out on this Ross, but I'm constrained to only one machine ATM :-(

Jonas, if I can help, just let me know!

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang

[Ross McDonald]

No worries Viktor, I only have multiple machines at work :-)

[rossputin]

Sorry for the delay on this. Lots of meetings and launches, all Akka
based you will be pleased to hear. I can confirm this does work as
expected, the problem was all my fault, too many versions of Akka
lying around for different work projects requiring different versions
of Scala. I did not pay enough attention to detail. I screwed up
with AKKA_HOME.

Sorry for wasting your time.

-- Ross

On Apr 21, 5:04 pm, Jonas Bonér <jo...@jonasboner.com> wrote:
> This should of course work. It has worked fine before. I even have had
> attendees having lab code talking with their neighbours laptop on my
> training sessions.
> Could be a regression.
> I'll look into it tomorrow.
>

[Jonas Bonér]

On 11 May 2010 18:04, rossputin <ross...@gmail.com> wrote:

Sorry for the delay on this.  Lots of meetings and launches, all Akka
based you will be pleased to hear.  I can confirm this does work as
expected, the problem was all my fault, too many versions of Akka
lying around for different work projects requiring different versions
of Scala.  I did not pay enough attention to detail.  I screwed up
with AKKA_HOME.

Sorry for wasting your time.

No worries Ross. Thanks for everything that you bring to the Akka community. 

Great to hear that it works.  

--
Jonas Bonér

work:   http://jayway.com

code:   http://akkasource.com

blog:    http://jonasboner.com
twitter: @jboner