- create RemoteActorRef in actorFor
- simplify send/receive because Futures/Exceptions do not go over the
wire anymore
- add RemoteCommunicationSpec which uses two ActorSystems communicating
in the same JVM via TCP socket
- moved RemoteInterface.scala into akka-remote, not needed anymore since
the plugin is loaded as ActorRefProvider now
- removed some old unused imports
- split out remote aspects from Deployer & DeployerSpec into
RemoteDeployer & RemoteDeployerSpec (the latter in akka-remote)
- created a ticket for cleaning up the rest, mostly remove all
occurrences of “remote” and “cluster” from akka-actor in this way
All of this was triggered by wanting to:
- change the signature of RemoteSupport.send to require a RemoteActorRef
recipient
- AkkaSpecSpec failed with nothing in the locker, but only on Jenkins
- cause: Davy Jones doesn’t get a chance to run because nobody actually
waits for his processing
- thus, give him permission to leave this world and have him confirm
that
- when no name was given, it resulted in a simple call to the provider
- which is completely the wrong thing to do in case of ActorSystem
- so, introduce CreateRandomNameChild op for guardians and use that
The reason for the previously failing test case was that Jenkins has
only two (logical) cores and the test config sets the
core-pool-size-factor to 2, meaning four threads. This is not enough to
have four Futures waiting (as per the test) and one actor which actually
does the work (the guardian in this case). Hence, make it so that
core-pool-size-min gives the absolute minimum and set the default of
that to eight.
While doing so I cleaned up the MessageDispatcherConfigurator to not use
HOF since now configuration items are not optional anymore, yielding a
flow which is much more readily understandable.
- I had reused akka.actor.timeout for ActorSystem.actorOf calls (which
“ask” the guardian to create the actor), but 5sec proved too short for
Jenkins
- CreationTimeout defaults to 30sec now, let’s hope Jenkins is not
slower than _that_.
