Needing clarification on DEBUG entry

32 views
Skip to first unread message

Diego Medina

unread,
Dec 28, 2011, 12:02:33 AM12/28/11
to akka...@googlegroups.com
Hi,

From this line:

[DEBUG] [12/27/2011 23:34:06.212] [New I/O server worker #1-2]
[NettyRemoteSupport] received message RemoteMessage: Message(1,1.0) to
Actor[akka://remote...@192.168.0.103:2552/deadLetters]<+{akka://remote...@192.168.0.103:2552/user/CometRemoteDispatcher1}
from Actor[akka://remote...@192.168.0.103:2552/deadLetters]

what does:

Actor[akka://remote...@192.168.0.103:2552/deadLetters]<+{akka://remote...@192.168.0.103:2552/user/CometRemoteDispatcher1}

mean?

specially the <+ ?

Thanks

Diego


--
Diego Medina
Web Developer
di...@fmpwizard.com
http://www.fmpwizard.com

rkuhn

unread,
Dec 28, 2011, 1:35:12 AM12/28/11
to akka...@googlegroups.com
Hi Diego,

it’s a debug message for something internal ;-) But it tells me that the destination you are sending to does not exist: before the funny sign you see the result of looking up the target (which is deadLetters i.e. failed) and after you see the actor path which was given in the remote message. The ASCII art in that message does not have any more special meaning.

Regards,

Roland

Diego Medina

unread,
Dec 28, 2011, 2:19:39 AM12/28/11
to akka...@googlegroups.com
On Wed, Dec 28, 2011 at 1:35 AM, rkuhn <goo...@rkuhn.info> wrote:
> Hi Diego,
>
> it’s a debug message for something internal ;-) But it tells me that the destination you are sending to does not exist: before the funny sign you see the result of looking up the target (which is deadLetters i.e. failed) and after you see the actor path which was given in the remote message. The ASCII art in that message does not have any more special meaning.

Hi Roland,

Well, this explains why my messages don't seem to make it to the
receive = { ...} block of code. I wonder what I'm doing wring, because
if I understood what you said, from this line:

what I "want to see" if

Actor[akka://remote...@192.168.0.103:2552/user/CometRemoteDispatcher1]<+{akka://remote...@192.168.0.103:2552/user/CometRemoteDispatcher1}

192.168.0.103 is my remote node, there I have a bare bones microkernel
that all it has in the bootable class is

val system = ActorSystem("remoteSystem")

then on my local machine (192.168.0.100 ) I don't use contex.actorFor,
but instead I use system.actorOf(new ActorClass)
and I use the config to tell akka to create my actors on the remote node.
One thing that may complicate things is that I have an actor I deploy
remotely, which works, but that actor, creates my
CometRemoteDispatcher1 actor, which I think gets created on
192.168.0.103 even if I don't tell it to be a remote actor using the
config file.

Maybe I should try hardcoding the actorFor() call just to see what happens.

Thanks

Diego

>
> Regards,
>
> Roland
>
> --
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/vRVZvYbM7j0J.
> 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.

rkuhn

unread,
Dec 28, 2011, 2:49:59 AM12/28/11
to akka...@googlegroups.com


Am Mittwoch, 28. Dezember 2011 08:19:39 UTC+1 schrieb fmpwizard:
On Wed, Dec 28, 2011 at 1:35 AM, rkuhn <goo...@rkuhn.info> wrote:
> Hi Diego,
>
> it’s a debug message for something internal ;-) But it tells me that the destination you are sending to does not exist: before the funny sign you see the result of looking up the target (which is deadLetters i.e. failed) and after you see the actor path which was given in the remote message. The ASCII art in that message does not have any more special meaning.

Hi Roland,

Well, this explains why my messages don't seem to make it to the
receive = { ...} block of code. I wonder what I'm doing wring, because
if I understood what you said, from this line:

Actor[akka://remoteSystem@192.168.0.103:2552/deadLetters]<+{akka://remote...@192.168.0.103:2552/user/CometRemoteDispatcher1}


what I "want to see" if

Actor[akka://remoteSystem@192.168.0.103:2552/user/CometRemoteDispatcher1]<+{akka://remote...@192.168.0.103:2552/user/CometRemoteDispatcher1}

192.168.0.103 is my remote node, there I have a bare bones microkernel
that all it has in the bootable class is

val system = ActorSystem("remoteSystem")

then on my local machine (192.168.0.100 ) I don't use contex.actorFor,
but instead I use system.actorOf(new ActorClass)
and I use the config to tell akka to create my actors on the remote node.
One thing that may complicate things is that I have an actor I deploy
remotely, which works, but that actor, creates my
CometRemoteDispatcher1 actor, which I think gets created on
192.168.0.103 even if I don't tell it to be a remote actor using the
config file.


Each child actor is created on the same node as its parent unless specifically configured otherwise. Also, if your CometRemoteDispatcher is the child of another actor, then the path you give above cannot be right, the parent’s name should be between /user and the last part. And if the parent is remotely deployed, the whole subtree will be shifted somewhere below /remote; this is the reason why I recommend looking up only logical paths, i.e. without taking into account configured deployment. But be sure to include the “root node” in the path, i.e. make it fully absolute with hostname and port where the whole system was started on (i.e. where the logical path starts).
 

Maybe I should try hardcoding the actorFor() call just to see what happens.


Also try printing out context.self in the created actor to see its true identity.


Regards,

Roland

Diego Medina

unread,
Dec 28, 2011, 8:15:58 AM12/28/11
to akka...@googlegroups.com
On Wed, Dec 28, 2011 at 2:49 AM, rkuhn <goo...@rkuhn.info> wrote:
>
>
> Am Mittwoch, 28. Dezember 2011 08:19:39 UTC+1 schrieb fmpwizard:
>>
>> On Wed, Dec 28, 2011 at 1:35 AM, rkuhn <goo...@rkuhn.info> wrote:
>> > Hi Diego,
>> >
>> > it’s a debug message for something internal ;-) But it tells me that the
>> > destination you are sending to does not exist: before the funny sign you see
>> > the result of looking up the target (which is deadLetters i.e. failed) and
>> > after you see the actor path which was given in the remote message. The
>> > ASCII art in that message does not have any more special meaning.
>>
>> Hi Roland,
>>
>> Well, this explains why my messages don't seem to make it to the
>> receive = { ...} block of code. I wonder what I'm doing wring, because
>> if I understood what you said, from this line:
>>
>> Actor[akka://remote...@192.168.0.103:2552/deadLetters]<+{akka://remote...@192.168.0.103:2552/user/CometRemoteDispatcher1}

>> what I "want to see" if
>>
>>
>> Actor[akka://remote...@192.168.0.103:2552/user/CometRemoteDispatcher1]<+{akka://remote...@192.168.0.103:2552/user/CometRemoteDispatcher1}

>>
>> 192.168.0.103 is my remote node, there I have a bare bones microkernel
>> that all it has in the bootable class is
>>
>> val system = ActorSystem("remoteSystem")
>>
>> then on my local machine (192.168.0.100 ) I don't use contex.actorFor,
>> but instead I use system.actorOf(new ActorClass)
>> and I use the config to tell akka to create my actors on the remote node.
>> One thing that may complicate things is that I have an actor I deploy
>> remotely, which works, but that actor, creates my
>> CometRemoteDispatcher1 actor, which I think gets created on
>> 192.168.0.103 even if I don't tell it to be a remote actor using the
>> config file.
>
>
> Each child actor is created on the same node as its parent unless
> specifically configured otherwise. Also, if your CometRemoteDispatcher is
> the child of another actor, then the path you give above cannot be right,
> the parent’s name should be between /user and the last part. And if the
> parent is remotely deployed, the whole subtree will be shifted somewhere
> below /remote; this is the reason why I recommend looking up only logical
> paths, i.e. without taking into account configured deployment. But be sure
> to include the “root node” in the path, i.e. make it fully absolute with
> hostname and port where the whole system was started on (i.e. where the
> logical path starts).
>

Thanks for this explanation, after rereading my code I realized that I
created the child actor using system.actorOf instead of
context.actorOf, now that I use context.actorOf I no longer get the
deadletter url, and my RemoteCometDispatcher is getting messages, now
on the next chain of actors I am getting:

[ERROR] [12/28/2011 08:11:27.266] [New I/O client worker #1-1]
[NettyRemoteSupport] dropping message Message(1,1.0) for non-local
recipient akka://local...@192.168.0.100:2552/user/akkacometbrother1


This actor, akkacometbrother1 is supposed to run locally on
192.168.0.103, and it is supposed to get a message from the remote
192.168.0.103 RemoteCometDispatcher1 actor.
Any pointers on how to solve this issue?

Again, thanks for all the help.

Diego


>>
>> Maybe I should try hardcoding the actorFor() call just to see what
>> happens.
>
>
> Also try printing out context.self in the created actor to see its true
> identity.
>

>
> Regards,
>
> Roland
>


> --
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/akka-user/-/5MgsK9vCMv0J.

rkuhn

unread,
Dec 28, 2011, 10:44:51 AM12/28/11
to akka...@googlegroups.com


Am Mittwoch, 28. Dezember 2011 14:15:58 UTC+1 schrieb fmpwizard:
On Wed, Dec 28, 2011 at 2:49 AM, rkuhn <goo...@rkuhn.info> wrote:
>
>
> Am Mittwoch, 28. Dezember 2011 08:19:39 UTC+1 schrieb fmpwizard:
>>
>> On Wed, Dec 28, 2011 at 1:35 AM, rkuhn <goo...@rkuhn.info> wrote:
>> > Hi Diego,
>> >
>> > it’s a debug message for something internal ;-) But it tells me that the
>> > destination you are sending to does not exist: before the funny sign you see
>> > the result of looking up the target (which is deadLetters i.e. failed) and
>> > after you see the actor path which was given in the remote message. The
>> > ASCII art in that message does not have any more special meaning.
>>
>> Hi Roland,
>>
>> Well, this explains why my messages don't seem to make it to the
>> receive = { ...} block of code. I wonder what I'm doing wring, because
>> if I understood what you said, from this line:
>>
>> Actor[akka://remoteSystem@192.168.0.103:2552/deadLetters]<+{akka://remote...@192.168.0.103:2552/user/CometRemoteDispatcher1}

>> what I "want to see" if
>>
>>
>> Actor[akka://remoteSystem@192.168.0.103:2552/user/CometRemoteDispatcher1]<+{akka://remote...@192.168.0.103:2552/user/CometRemoteDispatcher1}
Unfortunately not: in this case I would need my crystal ball in good working order to see your code … specifically: how do you obtain the ActorRef where you send (1, 1.0); it is not obvious to me how simple use of the API may result in this error message (as opposed to sending manually using protobuf and friends).

Regards,

Roland

Diego Medina

unread,
Dec 28, 2011, 2:28:32 PM12/28/11
to akka...@googlegroups.com

On Wed, Dec 28, 2011 at 10:44 AM, rkuhn <goo...@rkuhn.info> wrote:
>
>
> Am Mittwoch, 28. Dezember 2011 14:15:58 UTC+1 schrieb fmpwizard:
>>
>> On Wed, Dec 28, 2011 at 2:49 AM, rkuhn <goo...@rkuhn.info> wrote:
>> >
>> >
>> > Am Mittwoch, 28. Dezember 2011 08:19:39 UTC+1 schrieb fmpwizard:
>> >>
>> >> On Wed, Dec 28, 2011 at 1:35 AM, rkuhn <goo...@rkuhn.info> wrote:
>> >> > Hi Diego,
>> >> >
>> >> > it’s a debug message for something internal ;-) But it tells me that
>> >> > the
>> >> > destination you are sending to does not exist: before the funny sign
>> >> > you see
>> >> > the result of looking up the target (which is deadLetters i.e.
>> >> > failed) and
>> >> > after you see the actor path which was given in the remote message.
>> >> > The
>> >> > ASCII art in that message does not have any more special meaning.
>> >>
>> >> Hi Roland,
>> >>
>> >> Well, this explains why my messages don't seem to make it to the
>> >> receive = { ...} block of code. I wonder what I'm doing wring, because
>> >> if I understood what you said, from this line:
>> >>
>> >>

>> >> Actor[akka://remote...@192.168.0.103:2552/deadLetters]<+{akka://remote...@192.168.0.103:2552/user/CometRemoteDispatcher1}


>> >> what I "want to see" if
>> >>
>> >>
>> >>

>> >> Actor[akka://remote...@192.168.0.103:2552/user/CometRemoteDispatcher1]<+{akka://remote...@192.168.0.103:2552/user/CometRemoteDispatcher1}

:) , I have the code to create this akkacometbrother actor in a trait like this:

lazy val system= ActorSystem("localSystem")
lazy val actorName= "akkacometbrother" + name.openOr("")
lazy val actor= system.actorOf(Props(new AkkaCometBrother(this)), actorName)

/**
* First thing we do is registering this comet actor
* for the "name" key
*/
override def localSetup = {
info("\n\n====> Registering actor: %s \n\n".format(actor))
CometListerner.remoteListenerFor(name) ! registerCometActor(actor, name)
super.localSetup()
}

the localSetup is called when I visit a particular page on my web application.

this line:

CometListerner.remoteListenerFor(name) ! registerCometActor(actor, name)

does the following:

CometListerner.remoteListenerFor(name) returns an ActorRef (the remote CometRemoteDispatcher1 ) ,and then I send the message:
registerCometActor(actor, name)

Here actor is the akkacometbrother. I then store the akkacometbrother in a list.

Later on, another part of the app sends a message to the remote comet dispatcher, and based on the message, it returns the akkacometbrother from the list, so that it can process the new message.

I wonder if storing the actorref on a list on the remote node is the problem.

Hope this was clear.

Thanks

Diego
Sent from my cell



>
> Regards,
>
> Roland
>
> --
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/akka-user/-/EifVleqSA_EJ.


>
> 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.

√iktor Ҡlang

unread,
Dec 28, 2011, 4:16:02 PM12/28/11
to akka...@googlegroups.com
Hi Diego,

Why are you closing over "this" here?

 

actorName)


How is this trait used?



--
Viktor Klang

Akka Tech Lead
Typesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

Diego Medina

unread,
Dec 28, 2011, 4:55:34 PM12/28/11
to akka...@googlegroups.com

2011/12/28 √iktor Ҡlang <viktor...@gmail.com>:

"This" here is the enclosing Lift CometActor.

>
> How is this trait used?

I mix it in into this other class that defines what my Lift cometactor needs to do based on the messages I send

Something like:

class myFinalCometActor extends NamedCometActor

NamedCometActor is the trait that encloses the akkacometbrother and extends CometActor (a liftweb class)

If you wonder why I have this akkacometbrother actor, I use it because if I try to send the CometActor to the remote RemoteCometDispatcher I get a stack trace saying my class is not seriazable. So I thought I could send the ActorRef of an akka actor over the wire, and then when the akkacometbrother actor gets a message from the dispatcher  it would forward it to the lift comet actor.

Thanks for looking into this, I think that if I get past this error, I can finally get all the pieces working together

Diego

Diego Medina

unread,
Dec 28, 2011, 10:32:01 PM12/28/11
to akka...@googlegroups.com
Hi Roland, Viktor,

Some more information that hopefully will help you help me :)

These are log entries on the "remote node"

[DEBUG] [12/28/2011 21:40:07.754] [New I/O server worker #1-1]


[NettyRemoteSupport] received message RemoteMessage: Message(1,1.0) to

Actor[akka://RemoteCometDi...@192.168.0.103:2552/remote/CometList...@192.168.0.100:2552/user/RemoteCometListener/RemoteCometDispatcher1]<+{akka://RemoteCometDi...@192.168.0.103:2552/remote/CometList...@192.168.0.100:2552/user/RemoteCometListener/RemoteCometDispatcher1}
from Actor[akka://RemoteCometDi...@192.168.0.103:2552/deadLetters]
[DEBUG] [12/28/2011 21:40:07.755] [DefaultDispatcher-6] [RemoteClient]
Sending message: RemoteMessage: Message(1,1.0) to
Actor[akka://local...@192.168.0.100:2552/user/akkacometbrother1]<+{akka://local...@192.168.0.100:2552/user/akkacometbrother1}
from Actor[akka://RemoteCometDi...@192.168.0.103:2552/remote/CometList...@192.168.0.100:2552/user/RemoteCometListener/RemoteCometDispatcher1]


which does what I expect:
* The remote node gets the Message(1,1.0) message from the local
node, it then looks up the akkacometbrother actor that needs to get
that message and sends it to it (which is on the local node, at
192.168.0.100)


Now, on the local node I get these entries:

[DEBUG] [12/28/2011 21:40:08.100] [New I/O client worker #1-1]


[NettyRemoteSupport] received message RemoteMessage: Message(1,1.0) to

Actor[akka://local...@192.168.0.100:2552/user/akkacometbrother1]<+{akka://local...@192.168.0.100:2552/user/akkacometbrother1}
from Actor[akka://RemoteCometDi...@192.168.0.103:2552/remote/CometList...@192.168.0.100:2552/user/RemoteCometListener/RemoteCometDispatcher1]
[ERROR] [12/28/2011 21:40:08.101] [New I/O client worker #1-1]


[NettyRemoteSupport] dropping message Message(1,1.0) for non-local
recipient akka://local...@192.168.0.100:2552/user/akkacometbrother1

and here we have trouble. It says it receives the Message(1, 1.0),
which is correct, it even says that the message is sent to
"akka://local...@192.168.0.100:2552/user/akkacometbrother1" which
is correct, but then I get the dropping message for non-local
recipient error, which I don't know why it happens.

Thanks.

Diego

Diego Medina

unread,
Dec 28, 2011, 11:13:29 PM12/28/11
to akka...@googlegroups.com
Sorry for all the separate email but I got it working now!, well, it
works, but it doesn't look very "location transparent".

On my RemoteCometDispatcher akka actor I had this before

case msg => {
cometActorsToUpdate.foreach{ x => {
// x is the actor I got from a lookup on a List
x ! msg
info("We will update this comet actor: %s showing name:
%s".format(x, name))
}
}
}

but after changing it to

case msg => {
cometActorsToUpdate.foreach{ x => {
/**
* For some reason I need to create a temp system, just using x
* gives me an error on the other node like:
* dropping message ... to non-local ...
*/
val system= ActorSystem("temp")
val actor= system.actorFor(x.path)
actor ! msg
info("We will update this comet actor: %s showing name:
%s".format(x, name))
}
}
}

I no longer get the error message about the akkacometbrother not being
a local actor
I tried using context.actorFor(x.path) but that also gave me the same error.
Now, if I run the whole thing just locally, I don't need to add this
temp system and all the messages work well.

If you would like to look into why the location transparency does not
work in this setup, to see if there is something that needs to be
fixed in akka, I would be happy to send you a zip file of my project,
I just can't put it on github yet.

But it could be just the way I use it

Thanks for all your time!

Diego

--

√iktor Ҡlang

unread,
Dec 29, 2011, 12:29:51 AM12/29/11
to akka...@googlegroups.com
So how many ActorSystems do you end up creating?

Why are you creating one ActorSystem per LiftActor?
 

>
> How is this trait used?

I mix it in into this other class that defines what my Lift cometactor needs to do based on the messages I send

Something like:

class myFinalCometActor extends NamedCometActor

NamedCometActor is the trait that encloses the akkacometbrother and extends CometActor (a liftweb class)

If you wonder why I have this akkacometbrother actor, I use it because if I try to send the CometActor to the remote RemoteCometDispatcher I get a stack trace saying my class is not seriazable. 

So I thought I could send the ActorRef of an akka actor over the wire, and then when the akkacometbrother actor gets a message from the dispatcher  it would forward it to the lift comet actor.

It's perfectly fine to send ActorRefs (Akka) over the wire. How are you serializing your messages?

Diego Medina

unread,
Dec 29, 2011, 2:23:59 AM12/29/11
to akka...@googlegroups.com
2011/12/29 √iktor Ҡlang <viktor...@gmail.com>:

> So how many ActorSystems do you end up creating?

I end up creating 4 ActorSystems, two end up on the remote node, and
two on the local node. And after more testing I found out that the
order in which the two local actorSystems get ini'ed, then I get or
don't get the error about dropping the message to the the non-local
actor

>
>
> Why are you creating one ActorSystem per LiftActor?

Because I'm still learning how it all works :) , I'm going to try and
create just one actor System, at the start of the web app, and try to
reuse it across all my other actors, if that does not work, I guess
I'll try creating two actorsystems, one for the remote node, and one
for the local node, and see what happens.

Thanks

Diego

>
>>
>> >

√iktor Ҡlang

unread,
Dec 29, 2011, 2:41:48 AM12/29/11
to akka...@googlegroups.com
On Thu, Dec 29, 2011 at 8:23 AM, Diego Medina <di...@fmpwizard.com> wrote:
2011/12/29 √iktor Ҡlang <viktor...@gmail.com>:
> So how many ActorSystems do you end up creating?

I end up creating 4 ActorSystems, two end up on the remote node, and
two on the local node. And after more testing I found out that the
order in which the two local actorSystems get ini'ed, then I get or
don't get the error about dropping the message to the the non-local
actor

You should only have 1 ActorSystem per logical application per jvm.

Cheers,

Diego Medina

unread,
Dec 29, 2011, 2:42:48 AM12/29/11
to akka...@googlegroups.com
On Thu, Dec 29, 2011 at 2:23 AM, Diego Medina <di...@fmpwizard.com> wrote:
> 2011/12/29 √iktor Ҡlang <viktor...@gmail.com>:
>> So how many ActorSystems do you end up creating?
>
> I end up creating 4 ActorSystems, two end up on the remote node, and
> two on the local node. And after more testing I found out that the
> order in which the two local actorSystems get ini'ed, then I get or
> don't get the error about dropping the message to the the non-local
> actor
>
>>
>>
>> Why are you creating one ActorSystem per LiftActor?
>
> Because I'm still learning how it all works :) , I'm going to try and
> create just one actor System, at the start of the web app, and try to
> reuse it across all my other actors, if that does not work, I guess
> I'll try creating two actorsystems, one for the remote node, and one
> for the local node, and see what happens.

Ok, now I think it really works.
My final setup is:

On my remote node (so far I only have one remote node, I hope to try
more nodes in the coming days), I have a simple microkernel like:

class KernelNode extends Bootable with Logger {
val system = ActorSystem("RemoteCometDispatcherSystem")
...
}

I also have a jar in the classpath with the messages I pass to the
different actors

on my local (or master) node I have the full web application running
Lift, there I have one object that has:

object AkkaActorSystem {
val system = ActorSystem("system")
}

I then import this object and the system val into the other classes on
my web app so I can reuse the same system all over the place.
Because of how my app works, the config on the master node only
deploys one actor to the remote node:

/RemoteCometListener {
remote = "akka://RemoteCometDi...@192.168.0.103:2552"
}

that actor creates a child, which also ends up on the remote node, the
other actor(s) are local on the master node (which is what I want for
now)

On a previous email I said that I needed code like this:

case msg => {
cometActorsToUpdate.foreach{ x => {
/**

* For some reason I need to use an ActorSystem, just using x


* gives me an error on the other node like:
* dropping message ... to non-local ...
*/

import AkkaActorSystem.system


val actor= system.actorFor(x.path)
actor ! msg
info("We will update this comet actor: %s showing name:
%s".format(x, name))
}
}
}

instead of simply

case msg => {
cometActorsToUpdate.foreach{ x => {

x ! msg
info("We will update this comet actor: %s showing name:
%s".format(x, name))
}
}
}

but this is not true, I just changed it back to simply use x ! msg and
it works, it was not working before because I had more than one
actorsystem I guess.

Thanks!

Diego

Diego Medina

unread,
Dec 29, 2011, 2:43:41 AM12/29/11
to akka...@googlegroups.com
2011/12/29 √iktor Ҡlang <viktor...@gmail.com>:

>
>
> On Thu, Dec 29, 2011 at 8:23 AM, Diego Medina <di...@fmpwizard.com> wrote:
>>
>> 2011/12/29 √iktor Ҡlang <viktor...@gmail.com>:
>> > So how many ActorSystems do you end up creating?
>>
>> I end up creating 4 ActorSystems, two end up on the remote node, and
>> two on the local node. And after more testing I found out that the
>> order in which the two local actorSystems get ini'ed, then I get or
>> don't get the error about dropping the message to the the non-local
>> actor
>
>
> You should only have 1 ActorSystem per logical application per jvm.
>

Thanks, I totally missed reading that on the docs.

Diego

√iktor Ҡlang

unread,
Dec 29, 2011, 2:46:32 AM12/29/11
to akka...@googlegroups.com
Great to hear that it now works :-)

Please help us out in improving our docs!

Cheers,

rkuhn

unread,
Dec 29, 2011, 12:10:41 PM12/29/11
to akka...@googlegroups.com
Great that you got it working, hopefully your documented odyssey will help others who are reading the archives ;-)

BTW: I improved logging for the upcoming 2.0-M2, especially for non-existing actor paths (are not deadLetters now anymore).

Regards,

Roland

      /RemoteCometListener {
        remote = "akka://RemoteCometDispatcherSys...@192.168.0.103:2552"
      }

Diego Medina

unread,
Dec 29, 2011, 1:04:59 PM12/29/11
to akka...@googlegroups.com
On Thu, Dec 29, 2011 at 12:10 PM, rkuhn <goo...@rkuhn.info> wrote:
> Great that you got it working, hopefully your documented odyssey will help
> others who are reading the archives ;-)
>

They'll have plenty to read :)


> BTW: I improved logging for the upcoming 2.0-M2, especially for non-existing
> actor paths (are not deadLetters now anymore).
>

That's great, I'll make sure to upgrade to that once it is released.
My next adventure will be around disconnecting and connecting remote
nodes and see what happens, because in my real use case, the remote
nodes are going to be on unreliable networks, and while it is ok to
loose some messages, it needs to be able to reconnect if you keep
trying. But I'll start a new thread if I have issues there :)

Thanks

Diego

>>         remote = "akka://RemoteCometDi...@192.168.0.103:2552"

> https://groups.google.com/d/msg/akka-user/-/SdobhOHFzTAJ.

Diego Medina

unread,
Dec 29, 2011, 1:05:50 PM12/29/11
to akka...@googlegroups.com
2011/12/29 √iktor Ҡlang <viktor...@gmail.com>:

> Great to hear that it now works :-)
>
> Please help us out in improving our docs!
>

Sure, I haven't read how your contribution policy works but I'll be
happy to add docs around the areas where I had issues.

Diego


> Cheers,
> √

Reply all
Reply to author
Forward
0 new messages