ActorRefs as parts of messages

[√iktor Klang]

Hey guys,

I was a bit surprised to see this not working:

case class DoSmth(ref: ActorRef)
val a = actorOf[SomeActor].start

val c = RemoteClient.actorFor("someserve", "somehost",someport)

c ! DoSmth(a)

yields:

java.io.NotSerializableException: akka.actor.LocalActorRef
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164)
    at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
    at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
    at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
    at akka.serialization.Serializer$Java$class.toBinary(Serializer.scala:58)
    at akka.serialization.Serializer$Java$.toBinary(Serializer.scala:53)
    at akka.remote.MessageSerializer$.serialize(MessageSerializer.scala:71)
    at akka.serialization.RemoteActorSerialization$.createRemoteMessageProtocolBuilder(SerializationProtocol.scala:308)
    at akka.remote.RemoteClient.send(RemoteClient.scala:290)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at akka.util.ReflectiveAccess$RemoteClientModule$.send(ReflectiveAccess.scala:102)
    at akka.actor.RemoteActorRef.postMessageToMailbox(ActorRef.scala:1364)
    at akka.actor.ScalaActorRef$class.$bang(ActorRef.scala:1530)
    at akka.actor.RemoteActorRef.$bang(ActorRef.scala:1346)
    at akka.actor.ticket.Ticket506Spec$$anonfun$1$$anonfun$apply$mcV$sp$1.apply$mcV$sp(Ticket506Spec.scala:63)
    at akka.actor.ticket.Ticket506Spec$$anonfun$1$$anonfun$apply$mcV$sp$1.apply(Ticket506Spec.scala:47)
    at akka.actor.ticket.Ticket506Spec$$anonfun$1$$anonfun$apply$mcV$sp$1.apply(Ticket506Spec.scala:47)
    at org.scalatest.Spec$$anon$2.apply(Spec.scala:1388)
    at org.scalatest.Suite$class.withFixture(Suite.scala:1509)
    at akka.actor.ticket.Ticket506Spec.withFixture(Ticket506Spec.scala:41)
    at org.scalatest.Spec$class.runTest(Spec.scala:1385)
    at akka.actor.ticket.Ticket506Spec.runTest(Ticket506Spec.scala:41)
    at org.scalatest.Spec$$anonfun$org$scalatest$Spec$$runTestsInBranch$1.apply(Spec.scala:1310)
    at org.scalatest.Spec$$anonfun$org$scalatest$Spec$$runTestsInBranch$1.apply(Spec.scala:1299)
    at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:61)
    at scala.collection.immutable.List.foreach(List.scala:45)
    at org.scalatest.Spec$class.org$scalatest$Spec$$runTestsInBranch(Spec.scala:1298)
    at org.scalatest.Spec$$anonfun$org$scalatest$Spec$$runTestsInBranch$1.apply(Spec.scala:1318)
    at org.scalatest.Spec$$anonfun$org$scalatest$Spec$$runTestsInBranch$1.apply(Spec.scala:1299)
    at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:61)
    at scala.collection.immutable.List.foreach(List.scala:45)
    at org.scalatest.Spec$class.org$scalatest$Spec$$runTestsInBranch(Spec.scala:1298)
    at org.scalatest.Spec$class.runTests(Spec.scala:1520)
    at akka.actor.ticket.Ticket506Spec.runTests(Ticket506Spec.scala:41)
    at org.scalatest.Suite$class.run(Suite.scala:1804)
    at akka.actor.ticket.Ticket506Spec.org$scalatest$Spec$$super$run(Ticket506Spec.scala:41)
    at org.scalatest.Spec$class.run(Spec.scala:1597)
    at akka.actor.ticket.Ticket506Spec.run(Ticket506Spec.scala:41)
    at org.scalatest.tools.ScalaTestFramework$ScalaTestRunner.run(ScalaTestFramework.scala:40)
    at sbt.TestRunner.run(TestFramework.scala:52)
    at sbt.TestRunner.runTest$1(TestFramework.scala:66)
    at sbt.TestRunner.run(TestFramework.scala:75)
    at sbt.TestFramework$$anonfun$9$$anonfun$apply$11.runTest$2(TestFramework.scala:192)
    at sbt.TestFramework$$anonfun$9$$anonfun$apply$11$$anonfun$apply$12.apply(TestFramework.scala:203)
    at sbt.TestFramework$$anonfun$9$$anonfun$apply$11$$anonfun$apply$12.apply(TestFramework.scala:203)
    at sbt.NamedTestTask.run(TestFramework.scala:91)
    at sbt.ScalaProject$$anonfun$sbt$ScalaProject$$toTask$1.apply(ScalaProject.scala:187)
    at sbt.ScalaProject$$anonfun$sbt$ScalaProject$$toTask$1.apply(ScalaProject.scala:187)
    at sbt.TaskManager$Task.invoke(TaskManager.scala:62)
    at sbt.impl.RunTask.doRun$1(RunTask.scala:77)
    at sbt.impl.RunTask.runTask(RunTask.scala:85)
    at sbt.impl.RunTask.sbt$impl$RunTask$$runIfNotRoot(RunTask.scala:60)
    at sbt.impl.RunTask$$anonfun$runTasksExceptRoot$2.apply(RunTask.scala:48)
    at sbt.impl.RunTask$$anonfun$runTasksExceptRoot$2.apply(RunTask.scala:48)
    at sbt.Distributor$Run$Worker$$anonfun$2.apply(ParallelRunner.scala:131)
    at sbt.Distributor$Run$Worker$$anonfun$2.apply(ParallelRunner.scala:131)
    at sbt.Control$.trapUnit(Control.scala:19)
    at sbt.Distributor$Run$Worker.run(ParallelRunner.scala:131)


Bug?

Cheers,

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

[Jonas Bonér]

We never magically serialize anything. You need to serialize it first then send it as a message.

Guess we could detect it and do it automatically in this simple case, but what if the actorref is part of case class ? Should we do reflection? Static analysis?
--
Jonas Bonér
Specialist at Large
work: http://scalablesolutions.se
code: http://akka.io
twtr: @jboner

"√iktor Klang" <viktor...@gmail.com> wrote:

>Work: Scalable Solutions <http://www.scalablesolutions.se>

[√iktor Klang]

On Mon, Nov 8, 2010 at 2:33 PM, Jonas Bonér <jo...@jonasboner.com> wrote:

We never magically serialize anything. You need to serialize it first then send it as a message.

The problem is to know when your messages will be routed onto another machine, or if they are going to pass an actor with a durable mailbox.
 

Guess we could detect it and do it automatically in this simple case, but what if the actorref is part of case class ?

I think it should be transparent, it should try to look itself up in the local ActorRegistry, if it succeeds it'll become a LocalActorRef, if it fails it should materialize as a RemoteActorRef on the homeAddress.
This kind of goes hand-in-hand with my mail before regarding the homeaddress and remoteaddress.
 

Should we do reflection? Static analysis?

I guess it'd be a requirement for any serialization schemes to perform this invisible conversion.


(Spending some time re-imagining remoting).

Cheers,

 

[Jonas Bonér]

For the 'sender' reference we automatically do serialization to RemoteActorRef. Since we have control over it. 

I can't see how we can solve the 'send-arbitrary-message-with-some-actorref-somewhere-in-the-message-problem' generically. 

The docs state this clearly if I'm not mistaken.

What is the real problem here? 

--
Jonas Bonér

Jonas Bonér
Specialist at Large
work: http://scalablesolutions.se
code: http://akka.io

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

[√iktor Klang]

On Mon, Nov 8, 2010 at 4:33 PM, Jonas Bonér <jo...@jonasboner.com> wrote:

For the 'sender' reference we automatically do serialization to RemoteActorRef. Since we have control over it. 

I can't see how we can solve the 'send-arbitrary-message-with-some-actorref-somewhere-in-the-message-problem' generically. 

The docs state this clearly if I'm not mistaken.

What is the real problem here? 

I think that ActorRef should be serializable, just like sender, we can add readObject and writeObject to translate automatically, and we can decide if it should rematerialize as a Local or Remote ref.
Then we can add support in SJSON and Java-JSON as well since we basically control them.

The "real" problem is that it's not obvious that you need to promote your refs to another form if you want to make sure your messages don't barf when crossing VM boundraries. (i.e. being sent to an actor with a durable mailbox (which demands serialization) or crossing over the network, perhaps as a load-balancing action).

Do I make sense?
 

[Jonas Bonér]

On 8 November 2010 16:44, √iktor Klang <viktor...@gmail.com> wrote:

On Mon, Nov 8, 2010 at 4:33 PM, Jonas Bonér <jo...@jonasboner.com> wrote:

For the 'sender' reference we automatically do serialization to RemoteActorRef. Since we have control over it. 

I can't see how we can solve the 'send-arbitrary-message-with-some-actorref-somewhere-in-the-message-problem' generically. 

The docs state this clearly if I'm not mistaken.

What is the real problem here? 

I think that ActorRef should be serializable, just like sender, we can add readObject and writeObject to translate automatically, and we can decide if it should rematerialize as a Local or Remote ref.

They are already serializable using Protobuf. 

 

Then we can add support in SJSON and Java-JSON as well since we basically control them.

I don't like that. We will get into maintenance hell, we need to add this whenever we add a new protocol, and what if the user uses some protocol not "supported". Then its inconsistent. We have a one "right" way of serializing these now already, just one line of code.  

  

The "real" problem is that it's not obvious that you need to promote your refs to another form if you want to make sure your messages don't barf when crossing VM boundraries. (i.e. being sent to an actor with a durable mailbox (which demands serialization) or crossing over the network, perhaps as a load-balancing action).

Sending messages over the network is *never* transparent. Should not be. You always need to think about a protocol. 

The user can add the standard way of serializing (e.g. a solved problem) to his custom serialization protocol if he wants. 

 

I can't see how you can do this "magic" in a generally applicable way. Prove me wrong :-)

[√iktor Klang]

On Mon, Nov 8, 2010 at 5:01 PM, Jonas Bonér <jo...@jonasboner.com> wrote:

On 8 November 2010 16:44, √iktor Klang <viktor...@gmail.com> wrote:

On Mon, Nov 8, 2010 at 4:33 PM, Jonas Bonér <jo...@jonasboner.com> wrote:

For the 'sender' reference we automatically do serialization to RemoteActorRef. Since we have control over it. 

I can't see how we can solve the 'send-arbitrary-message-with-some-actorref-somewhere-in-the-message-problem' generically. 

The docs state this clearly if I'm not mistaken.

What is the real problem here? 

I think that ActorRef should be serializable, just like sender, we can add readObject and writeObject to translate automatically, and we can decide if it should rematerialize as a Local or Remote ref.

They are already serializable using Protobuf. 

 

Then we can add support in SJSON and Java-JSON as well since we basically control them.

I don't like that. We will get into maintenance hell, we need to add this whenever we add a new protocol, and what if the user uses some protocol not "supported". Then its inconsistent. We have a one "right" way of serializing these now already, just one line of code.  

Hmm, not sure I follow, an example of the oneliner?
 

  

The "real" problem is that it's not obvious that you need to promote your refs to another form if you want to make sure your messages don't barf when crossing VM boundraries. (i.e. being sent to an actor with a durable mailbox (which demands serialization) or crossing over the network, perhaps as a load-balancing action).

Sending messages over the network is *never* transparent.

actorOf( new Actor {
  def receive = {
    case msg => self.reply("foo") //if self is a remote actor ref, this is a transparent network send
  }
})
 

Should not be. You always need to think about a protocol. 

The user can add the standard way of serializing (e.g. a solved problem) to his custom serialization protocol if he wants. 

 

I can't see how you can do this "magic" in a generally applicable way. Prove me wrong :-)

What you can do is to have a shared unit test contract for all serialization schemes, that enforces promotion on ActorRefs in messages to be serialized correctly.

For Java-serialization it's just implementing writeObject and readObject on ActorRef, for the others it may, or may not be harder.

We only need to send as much information as needed by a RemoteActorRef, the when we deserialize the ref, we check if the ActorRegistry contains the actor locally, then we return that, and if it doesn't, we materialize it as a RemoteActorRef pointing back to the origin.
 

[Jonas Bonér]

On 8 November 2010 17:18, √iktor Klang <viktor...@gmail.com> wrote:

On Mon, Nov 8, 2010 at 5:01 PM, Jonas Bonér <jo...@jonasboner.com> wrote:

On 8 November 2010 16:44, √iktor Klang <viktor...@gmail.com> wrote:

On Mon, Nov 8, 2010 at 4:33 PM, Jonas Bonér <jo...@jonasboner.com> wrote:

For the 'sender' reference we automatically do serialization to RemoteActorRef. Since we have control over it. 

I can't see how we can solve the 'send-arbitrary-message-with-some-actorref-somewhere-in-the-message-problem' generically. 

The docs state this clearly if I'm not mistaken.

What is the real problem here? 

I think that ActorRef should be serializable, just like sender, we can add readObject and writeObject to translate automatically, and we can decide if it should rematerialize as a Local or Remote ref.

They are already serializable using Protobuf. 

 

Then we can add support in SJSON and Java-JSON as well since we basically control them.

I don't like that. We will get into maintenance hell, we need to add this whenever we add a new protocol, and what if the user uses some protocol not "supported". Then its inconsistent. We have a one "right" way of serializing these now already, just one line of code.  

Hmm, not sure I follow, an example of the oneliner?

http://doc.akkasource.org/serialization-scala#Serialization%20of%20ActorRef-Serialization%20of%20a%20RemoteActorRef

 

 

  

The "real" problem is that it's not obvious that you need to promote your refs to another form if you want to make sure your messages don't barf when crossing VM boundraries. (i.e. being sent to an actor with a durable mailbox (which demands serialization) or crossing over the network, perhaps as a load-balancing action).

Sending messages over the network is *never* transparent.

actorOf( new Actor {
  def receive = {
    case msg => self.reply("foo") //if self is a remote actor ref, this is a transparent network send
  }
})

An actor can't just magically become remote, so it is not transparent. 

 

 

Should not be. You always need to think about a protocol. 

The user can add the standard way of serializing (e.g. a solved problem) to his custom serialization protocol if he wants. 

 

I can't see how you can do this "magic" in a generally applicable way. Prove me wrong :-)

What you can do is to have a shared unit test contract for all serialization schemes, that enforces promotion on ActorRefs in messages to be serialized correctly.

But this is a solved problem. We have correct and efficient serialization for ActorRef already.

For Java-serialization it's just implementing writeObject and readObject on ActorRef, for the others it may, or may not be harder.

That would be a no-brainer, we could just delegate to standard ActorRef serialization, so could be useful.

Please also note that this is *only* for serialization to RemoteActorRef, serialization to LocalActorRef requires (for stateful actors) user specific coding to serialize the Actor instance. 

[√iktor Klang]

On Mon, Nov 8, 2010 at 5:30 PM, Jonas Bonér <jo...@jonasboner.com> wrote:

On 8 November 2010 17:18, √iktor Klang <viktor...@gmail.com> wrote:

On Mon, Nov 8, 2010 at 5:01 PM, Jonas Bonér <jo...@jonasboner.com> wrote:

On 8 November 2010 16:44, √iktor Klang <viktor...@gmail.com> wrote:

On Mon, Nov 8, 2010 at 4:33 PM, Jonas Bonér <jo...@jonasboner.com> wrote:

For the 'sender' reference we automatically do serialization to RemoteActorRef. Since we have control over it. 

I can't see how we can solve the 'send-arbitrary-message-with-some-actorref-somewhere-in-the-message-problem' generically. 

The docs state this clearly if I'm not mistaken.

What is the real problem here? 

I think that ActorRef should be serializable, just like sender, we can add readObject and writeObject to translate automatically, and we can decide if it should rematerialize as a Local or Remote ref.

They are already serializable using Protobuf. 

 

Then we can add support in SJSON and Java-JSON as well since we basically control them.

I don't like that. We will get into maintenance hell, we need to add this whenever we add a new protocol, and what if the user uses some protocol not "supported". Then its inconsistent. We have a one "right" way of serializing these now already, just one line of code.  

Hmm, not sure I follow, an example of the oneliner?

http://doc.akkasource.org/serialization-scala#Serialization%20of%20ActorRef-Serialization%20of%20a%20RemoteActorRef

 

 

  

The "real" problem is that it's not obvious that you need to promote your refs to another form if you want to make sure your messages don't barf when crossing VM boundraries. (i.e. being sent to an actor with a durable mailbox (which demands serialization) or crossing over the network, perhaps as a load-balancing action).

Sending messages over the network is *never* transparent.

actorOf( new Actor {
  def receive = {
    case msg => self.reply("foo") //if self is a remote actor ref, this is a transparent network send
  }
})

An actor can't just magically become remote, so it is not transparent. 

No, of course not, but the guy writing the code above does not know whether he's going to receive a message from a remote actor or not. Also, if he assumes he's only going to reply to local actors and then somewhere down the line he starts using remote actors, he'll be pretty surprised to see that the code goes through the compiler and tests and then it fails runtime.

 

 

 

Should not be. You always need to think about a protocol. 

The user can add the standard way of serializing (e.g. a solved problem) to his custom serialization protocol if he wants. 

 

I can't see how you can do this "magic" in a generally applicable way. Prove me wrong :-)

What you can do is to have a shared unit test contract for all serialization schemes, that enforces promotion on ActorRefs in messages to be serialized correctly.

But this is a solved problem. We have correct and efficient serialization for ActorRef already.

We have the serialization, but not the materialize-as-Local-or-Remote yet. But we do have a ticket for that.
 

For Java-serialization it's just implementing writeObject and readObject on ActorRef, for the others it may, or may not be harder.

That would be a no-brainer, we could just delegate to standard ActorRef serialization, so could be useful.

Indeed.
 

Please also note that this is *only* for serialization to RemoteActorRef, serialization to LocalActorRef requires (for stateful actors) user specific coding to serialize the Actor instance. 

Yes I am sorry if I made this sound like I was talking about all serialization. I'm only talking about ActorRefs being passed in messages.
 

[Jonas Bonér]

On 8 November 2010 17:36, √iktor Klang <viktor...@gmail.com> wrote:

On Mon, Nov 8, 2010 at 5:30 PM, Jonas Bonér <jo...@jonasboner.com> wrote:

On 8 November 2010 17:18, √iktor Klang <viktor...@gmail.com> wrote:

On Mon, Nov 8, 2010 at 5:01 PM, Jonas Bonér <jo...@jonasboner.com> wrote:

On 8 November 2010 16:44, √iktor Klang <viktor...@gmail.com> wrote:

On Mon, Nov 8, 2010 at 4:33 PM, Jonas Bonér <jo...@jonasboner.com> wrote:

For the 'sender' reference we automatically do serialization to RemoteActorRef. Since we have control over it. 

I can't see how we can solve the 'send-arbitrary-message-with-some-actorref-somewhere-in-the-message-problem' generically. 

The docs state this clearly if I'm not mistaken.

What is the real problem here? 

I think that ActorRef should be serializable, just like sender, we can add readObject and writeObject to translate automatically, and we can decide if it should rematerialize as a Local or Remote ref.

They are already serializable using Protobuf. 

 

Then we can add support in SJSON and Java-JSON as well since we basically control them.

I don't like that. We will get into maintenance hell, we need to add this whenever we add a new protocol, and what if the user uses some protocol not "supported". Then its inconsistent. We have a one "right" way of serializing these now already, just one line of code.  

Hmm, not sure I follow, an example of the oneliner?

http://doc.akkasource.org/serialization-scala#Serialization%20of%20ActorRef-Serialization%20of%20a%20RemoteActorRef

 

 

  

The "real" problem is that it's not obvious that you need to promote your refs to another form if you want to make sure your messages don't barf when crossing VM boundraries. (i.e. being sent to an actor with a durable mailbox (which demands serialization) or crossing over the network, perhaps as a load-balancing action).

Sending messages over the network is *never* transparent.

actorOf( new Actor {
  def receive = {
    case msg => self.reply("foo") //if self is a remote actor ref, this is a transparent network send
  }
})

An actor can't just magically become remote, so it is not transparent. 

No, of course not, but the guy writing the code above does not know whether he's going to receive a message from a remote actor or not. Also, if he assumes he's only going to reply to local actors and then somewhere down the line he starts using remote actors, he'll be pretty surprised to see that the code goes through the compiler and tests and then it fails runtime.

You mean that the 'sender' ref in the 'reply' call is a remote actor? Then it is working, since they are automatically serialized. 

 

 

 

 

Should not be. You always need to think about a protocol. 

The user can add the standard way of serializing (e.g. a solved problem) to his custom serialization protocol if he wants. 

 

I can't see how you can do this "magic" in a generally applicable way. Prove me wrong :-)

What you can do is to have a shared unit test contract for all serialization schemes, that enforces promotion on ActorRefs in messages to be serialized correctly.

But this is a solved problem. We have correct and efficient serialization for ActorRef already.

We have the serialization, but not the materialize-as-Local-or-Remote yet. But we do have a ticket for that.
 

For Java-serialization it's just implementing writeObject and readObject on ActorRef, for the others it may, or may not be harder.

That would be a no-brainer, we could just delegate to standard ActorRef serialization, so could be useful.

Indeed.

Add this. And sketch up a design how you would solve it generically across all serialization schemes. 

[√iktor Klang]

Yes, it works for the sender, but consider this:

self.reply(SomeMessage(self)) //KaPow! self is a LocalActorRef and isn't serialized automagically

This means that if we have messages like that, we need to rewrite them all to use Array[Byte] and do everything by hand. I was hoping to fix that with some automagic voodoo glue
 

 

 

 

 

Should not be. You always need to think about a protocol. 

The user can add the standard way of serializing (e.g. a solved problem) to his custom serialization protocol if he wants. 

 

I can't see how you can do this "magic" in a generally applicable way. Prove me wrong :-)

What you can do is to have a shared unit test contract for all serialization schemes, that enforces promotion on ActorRefs in messages to be serialized correctly.

But this is a solved problem. We have correct and efficient serialization for ActorRef already.

We have the serialization, but not the materialize-as-Local-or-Remote yet. But we do have a ticket for that.
 

For Java-serialization it's just implementing writeObject and readObject on ActorRef, for the others it may, or may not be harder.

That would be a no-brainer, we could just delegate to standard ActorRef serialization, so could be useful.

Indeed.

Add this. And sketch up a design how you would solve it generically across all serialization schemes. 

I'll try it. Since all types are known statically: LocalActorRef and RemoteActorRef, it "should" work.
 

[Jonas Bonér]

Yes. Some voodoo might be good but it is usually mainly used for evil. :-)

Take a stab at it. But is this high prio really, e.g. needed for 1.0?

[√iktor Klang]

With great dark powers come great dark responsibility ;)
 

Take a stab at it. But is this high prio really, e.g. needed for 1.0?

If we're going to overhaul remote for 1.0 I'd say we might as well do it then. Otherwise we can aim for 1.1 since it isn't strictly related to the overhaul.
 

[Jonas Bonér]

Depends on how much work it is. Don't want to slow down the release. How fast can you do it? 

[√iktor Klang]

No clue. Will take a stab at it soon.

On Nov 8, 2010 6:35 PM, "Jonas Bonér" <jo...@jonasboner.com> wrote:

Depends on how much work it is. Don't want to slow down the release. How fast can you do it? 

On 8 November 2010 18:02, √iktor Klang <viktor...@gmail.com> wrote:
>
>
>

> On Mon, Nov 8, 2010...