multiple actor systems in the same jvm

[Ivan Porto Carrero]

Hi,

Can I message between actors in different actor systems but still in the same jvm?

Is this supposed to work: https://gist.github.com/1554237

or do I need to set up remote support to make that work?

Thanks,

Ivan

[Patrik Nordwall]

There is no global registry of actor systems in the jvm so this line doesn't work as you intend

val a = context.system.actorFor("akka://first/user/tester")

The context.system is the "second" system, and that knows nothing about "first" system.

One solution is to pass in ActorRef of "first actor" in constructor to "second actor", i.e. do the actorFor outside, where you have sys1.

Alternatively, in this sample you can do

val a = sys1.actorFor("akka://first/user/tester")

but it is seldom you close over vals like that in real applications.

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

--

Patrik Nordwall
Typesafe - Enterprise-Grade Scala from the Experts
Twitter: @patriknw

[Ivan Porto Carrero]

Ok, so I suppose I need to make use of the remote support to achieve this. 

The next question then becomes does the remote support use a local transport within the same jvm or does it always use TCP/IP?

It's a very simplified case in the example and actors in sys1 can't see actors in sys2.

I've also noticed that in my tests when I call system.shutdown it doesn't actually shut down the systems dispatchers and scheduler.

I've had to restructure some specs to share the actor system because it would lead to 1000+ threads being created in a single spec with many examples. most of them would have a thread dump like this:

"default-dispatcher18" prio=5 tid=7f866d471800 nid=0x1875fe000 waiting on condition [1875fd000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <7b5f77a80> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:196)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2025)
	at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:424)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
	at java.lang.Thread.run(Thread.java:680)

   Locked ownable synchronizers:
	- None

"DefaultScheduler1" prio=5 tid=7f8675022800 nid=0x154fa3000 waiting on condition [154fa2000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
	at java.lang.Thread.sleep(Native Method)
	at java.lang.Thread.sleep(Thread.java:302)
	at org.jboss.netty.akka.util.HashedWheelTimer$Worker.waitForNextTick(HashedWheelTimer.java:403)
	at org.jboss.netty.akka.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:319)
	at java.lang.Thread.run(Thread.java:680)

   Locked ownable synchronizers:
	- None

[Patrik Nordwall]

On Tue, Jan 3, 2012 at 11:03 AM, Ivan Porto Carrero <iv...@flanders.co.nz> wrote:

Ok, so I suppose I need to make use of the remote support to achieve this. 

The next question then becomes does the remote support use a local transport within the same jvm or does it always use TCP/IP?

I think it uses Netty even though it's the same jvm. I'm not sure if there is already some clever optimization for this in Netty.

We might optimize this later.

 

It's a very simplified case in the example and actors in sys1 can't see actors in sys2.

I've also noticed that in my tests when I call system.shutdown it doesn't actually shut down the systems dispatchers and scheduler.

I've had to restructure some specs to share the actor system because it would lead to 1000+ threads being created in a single spec with many examples. most of them would have a thread dump like this:

Could you file a ticket with a failing test case for this. We have many tests in Akka and each create it's own ActorSystem. We have carefully profiled proper shutdown and don't see any memory or thread leaks.

 

"default-dispatcher18" prio=5 tid=7f866d471800 nid=0x1875fe000 waiting on condition [1875fd000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <7b5f77a80> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:196)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2025)
	at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:424)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
	at java.lang.Thread.run(Thread.java:680)


   Locked ownable synchronizers:
	- None


"DefaultScheduler1" prio=5 tid=7f8675022800 nid=0x154fa3000 waiting on condition [154fa2000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
	at java.lang.Thread.sleep(Native Method)
	at java.lang.Thread.sleep(Thread.java:302)

	at org.jboss.netty.akka.util.HashedWheelTimer$Worker.waitForNextTick(HashedWheelTimer.java:403)
	at org.jboss.netty.akka.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:319)
	at java.lang.Thread.run(Thread.java:680)


   Locked ownable synchronizers:
	- None

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

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.

[G J]

A related question is if communication between actors in a remote
actor system is local.

Specifically:
1) ActorSystem uses the RemoteActorRefProvider and NettyRemoteSupport
2) Actors within the above system have remote support, and can be
accessed via IP:Port.
3) Does communication between actors within the system involve the TCP/
IP protocol stack, or is it a direct write into the actors mailbox?

Thanks.

On Jan 3, 4:41 am, Patrik Nordwall <patrik.nordw...@gmail.com> wrote:
> There is no global registry of actor systems in the jvm so this line
> doesn't work as you intend
> val a = context.system.actorFor("akka://first/user/tester")
>
> The context.system is the "second" system, and that knows nothing about
> "first" system.
>
> One solution is to pass in ActorRef of "first actor" in constructor to
> "second actor", i.e. do the actorFor outside, where you have sys1.
>
> Alternatively, in this sample you can do
> val a = sys1.actorFor("akka://first/user/tester")
> but it is seldom you close over vals like that in real applications.
>

> On Tue, Jan 3, 2012 at 10:26 AM, Ivan Porto Carrero <i...@flanders.co.nz>wrote:
>
>
>
>
>
>
>
>
>
> > Hi,
>
> > Can I message between actors in different actor systems but still in the
> > same jvm?
> > Is this supposed to work:https://gist.github.com/1554237
>
> > or do I need to set up remote support to make that work?
>
> > Thanks,
> > Ivan
>
> >  --
> > 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/-/IywF9q3EYMQJ.
> > 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.
>
> --
>
> Patrik Nordwall

> Typesafe <http://typesafe.com/> - Enterprise-Grade Scala from the Experts
> Twitter: @patriknw

[rkuhn]

Am Dienstag, 3. Januar 2012 16:25:57 UTC+1 schrieb G J:

A related question is if communication between actors in a remote
actor system is local.

Specifically:
1) ActorSystem uses the RemoteActorRefProvider and NettyRemoteSupport
2) Actors within the above system have remote support, and can be
accessed via IP:Port.
3) Does communication between actors within the system involve the TCP/
IP protocol stack, or is it a direct write into the actors mailbox?

Addresses with the local system’s name, host and port are resolved to local actor refs, meaning that no network transport is used. Any other address will use remoting.

Regards,

Roland

[Jonas Bonér]

We should optimize it. Create a ticket.

--
Jonas Bonér
CTO

Typesafe - Enterprise-Grade Scala from the Experts

Phone: +46 733 777 123
Twitter: @jboner

[Patrik Nordwall]

Created Performance ticket: http://www.assembla.com/spaces/akka/tickets/1603-optimize-remote-send-in-same-jvm

[G J]

Is there an ETA for this?

One workaround would be to have two actor systems: the first system
being a proxy to the outside world, and the second being all the
actors running without remoting. Only, you'd have two ActorSystems in
the same JVM. Would that create a problem?

Thanks.

On Jan 4, 4:16 am, Patrik Nordwall <patrik.nordw...@gmail.com> wrote:
> Created Performance ticket:http://www.assembla.com/spaces/akka/tickets/1603-optimize-remote-send...

>
>
>
>
>
>
>
>
>
> On Wed, Jan 4, 2012 at 9:49 AM, Jonas Bonér <jo...@jonasboner.com> wrote:
> > We should optimize it. Create a ticket.
>
> > --
> > Jonas Bonér
> > CTO
> > Typesafe - Enterprise-Grade Scala from the Experts
> > Phone: +46 733 777 123
> > Twitter: @jboner
>

> > On Jan 3, 2012 11:15 AM, "Patrik Nordwall" <patrik.nordw...@gmail.com>
> > wrote:

> >> Typesafe <http://typesafe.com/> - Enterprise-Grade Scala from the Experts

> >> Twitter: @patriknw
>
> >>  --
> >> 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.
>
> --
>
> Patrik Nordwall

> Typesafe <http://typesafe.com/> - Enterprise-Grade Scala from the Experts
> Twitter: @patriknw

[Patrik Nordwall]

On Wed, Jan 4, 2012 at 11:08 AM, G J <oda...@gmail.com> wrote:

Is there an ETA for this?

One workaround would be to have two actor systems: the first system
being a proxy to the outside world, and the second being all the
actors running without remoting. Only, you'd have two ActorSystems in
the same JVM. Would that create a problem?

I'm sure we will be able to optimize this in a good way, if possible. One of the major themes of 2.x is that we strive for location transparency.

--

Patrik Nordwall
Typesafe - Enterprise-Grade Scala from the Experts
Twitter: @patriknw