Singleton cluster actor is not starting up - scala

The following cluster singleton is not starting up.
commander = system.actorOf(
ClusterSingletonManager.props(Commander.props(this),
terminationMessage = PoisonPill.getInstance,
settings = ClusterSingletonManagerSettings.create(system).withRole("commander")
), name = "Commander")
No error messages are thrown.
Logs are:
[INFO] [08/03/2016 11:43:58.656] [ScalaTest-run-running-ClusterSuite] [akka.remote.Remoting] Starting remoting
[INFO] [08/03/2016 11:43:59.007] [ScalaTest-run-running-ClusterSuite] [akka.remote.Remoting] Remoting started; listening on addresses :[akka.tcp://galaxyFarFarAway#127.0.0.1:59592]
[INFO] [08/03/2016 11:43:59.035] [ScalaTest-run-running-ClusterSuite] [akka.cluster.Cluster(akka://galaxyFarFarAway)] Cluster Node [akka.tcp://galaxyFarFarAway#127.0.0.1:59592] - Starting up...
[INFO] [08/03/2016 11:43:59.218] [ScalaTest-run-running-ClusterSuite] [akka.cluster.Cluster(akka://galaxyFarFarAway)] Cluster Node [akka.tcp://galaxyFarFarAway#127.0.0.1:59592] - Registered cluster JMX MBean [akka:type=Cluster]
[INFO] [08/03/2016 11:43:59.218] [ScalaTest-run-running-ClusterSuite] [akka.cluster.Cluster(akka://galaxyFarFarAway)] Cluster Node [akka.tcp://galaxyFarFarAway#127.0.0.1:59592] - Started up successfully
[INFO] [08/03/2016 11:43:59.247] [galaxyFarFarAway-akka.actor.default-dispatcher-2] [akka.cluster.Cluster(akka://galaxyFarFarAway)] Cluster Node [akka.tcp://galaxyFarFarAway#127.0.0.1:59592] - Metrics will be retreived from MBeans, and may be incorrect on some platforms. To increase metric accuracy add the 'sigar.jar' to the classpath and the appropriate platform-specific native libary to 'java.library.path'. Reason: java.lang.ClassNotFoundException: org.hyperic.sigar.Sigar
[INFO] [08/03/2016 11:43:59.257] [galaxyFarFarAway-akka.actor.default-dispatcher-2] [akka.cluster.Cluster(akka://galaxyFarFarAway)] Cluster Node [akka.tcp://galaxyFarFarAway#127.0.0.1:59592] - Metrics collection has started successfully
[INFO] [08/03/2016 11:43:59.268] [galaxyFarFarAway-akka.actor.default-dispatcher-3] [akka.cluster.Cluster(akka://galaxyFarFarAway)] Cluster Node [akka.tcp://galaxyFarFarAway#127.0.0.1:59592] - No seed-nodes configured, manual cluster join required
Disconnected from the target VM, address: '127.0.0.1:59574', transport: 'socket'
The configuration is:
akka {
actor {
provider = "akka.cluster.ClusterActorRefProvider"
default-dispatcher {
throughput = 10
}
}
cluster {
roles = [commander]
}
remote {
log-remote-lifecycle-events = off
netty.tcp {
hostname = "127.0.0.1"
port = 0
}
}
akka.extensions=["akka.cluster.metrics.ClusterMetricsExtension"]
}
When I debug the code of Commander class, the constructor is not even called anywhere. When I omit the ClusterSingletonManager and just create it with Props it does work however, the Commander actor is going to be created.
I sense incorrect configuration behind this issue. Do you guys have any remarks about this?

You've sensed quite right: you haven't specified the seed node configuration for the Akka clustering. You can see this in the last line of the log:
[akka.tcp://galaxyFarFarAway#127.0.0.1:59592] - No seed-nodes configured, manual cluster join required Disconnected from the target VM, address: '127.0.0.1:59574', transport: 'socket'
Because you haven't specified any seed nodes in the configuration file, Akka will wait for you to specify the seed nodes programmatically. You can specify the seed nodes in the config like this:
akka.cluster.seed-nodes = [
"akka.tcp://yourClusterSystem#127.0.0.1:2551",
"akka.tcp://yourClusterSystem#127.0.0.1:2552"
]
Alternatively, you can call the joinSeedNodes method to join the cluster programmatically. In both cases, you have to specify at least one seed node that is available. The actor system itself can also act as a seed node.
Once the seed nodes have been specified and the actor system has joined the cluster, Akka features depending on clustering (cluster singletons, sharding etc.) will boot up. This is why you can launch an ordinary actor, but not the singleton.
For more information on setting up seed nodes see Akka cluster documentation.

Related

Setting up Akka cluster for Lagom application in production mode

I'm trying to run a Lagom service in production mode in an Akka cluster, which is configured via Akka Cluster Bootstrap as described in https://www.lagomframework.com/documentation/1.5.x/scala/Cluster.html. (I was able to run the app by specifying seed nodes manually). However, I could not manage to start the service. I have the following setup:
application.conf (only the cluster related configs)
akka.management.cluster.bootstrap {
# example using kubernetes-api
contact-point-discovery {
discovery-method = akka.discovery
# discovery-method = config
service-name = "lagom-scala"
required-contact-point-nr = 0
}
}
An application loader, loading the AkkaDiscoveryComponents in the production mode as described here (https://www.lagomframework.com/documentation/1.5.x/scala/AkkaDiscoveryIntegration.html):
class LagomscalaLoader extends LagomApplicationLoader {
override def load(context: LagomApplicationContext): LagomApplication =
new LagomscalaApplication(context) with AkkaDiscoveryComponents
override def loadDevMode(context: LagomApplicationContext): LagomApplication =
new LagomscalaApplication(context) with LagomDevModeComponents
override def describeService = Some(readDescriptor[LagomscalaService])
}
I get the following logs when required-contact-point-nr is set to 0:
2019-10-28T23:48:54.867Z [info] akka.management.cluster.bootstrap.internal.BootstrapCoordinator [sourceThread=application-akka.actor.default-dispatcher-26, akkaTimestamp=23:48:54.867UTC, akkaSource=akka.tcp://application#192.168.0.34:2552/system/bootstrapCoordinator, sourceActorSystem=application] - Looking up [Lookup(lagom-scala,None,Some(tcp))]
2019-10-28T23:48:54.886Z [info] akka.management.cluster.bootstrap.internal.BootstrapCoordinator [sourceThread=application-akka.actor.default-dispatcher-22, akkaTimestamp=23:48:54.886UTC, akkaSource=akka.tcp://application#192.168.0.34:2552/system/bootstrapCoordinator, sourceActorSystem=application] - Located service members based on: [Lookup(lagom-scala,None,Some(tcp))]: [], filtered to []
2019-10-28T23:48:55.957Z [info] akka.management.cluster.bootstrap.LowestAddressJoinDecider [sourceThread=application-akka.actor.default-dispatcher-16, akkaTimestamp=23:48:55.957UTC, akkaSource=LowestAddressJoinDecider(akka://application), sourceActorSystem=application] - Exceeded stable margins without locating seed-nodes, however this node 192.168.0.34:8558 is NOT the lowest address out of the discovered endpoints in this deployment, thus NOT joining self. Expecting node [] (out of []) to perform the self-join and initiate the cluster.
When I set required-contact-point-nr to 2 (default), I get the following logs:
2019-10-29T00:15:57.846Z [info] akka.management.cluster.bootstrap.internal.BootstrapCoordinator [sourceThread=application-akka.actor.default-dispatcher-23, akkaTimestamp=00:15:57.846UTC, akkaSource=akka.tcp://application#192.168.0.34:2552/system/bootstrapCoordinator, sourceActorSystem=application] - Looking up [Lookup(lagom-scala,None,Some(tcp))]
2019-10-29T00:15:57.865Z [info] akka.management.cluster.bootstrap.internal.BootstrapCoordinator [sourceThread=application-akka.actor.default-dispatcher-4, akkaTimestamp=00:15:57.865UTC, akkaSource=akka.tcp://application#192.168.0.34:2552/system/bootstrapCoordinator, sourceActorSystem=application] - Located service members based on: [Lookup(lagom-scala,None,Some(tcp))]: [], filtered to []
2019-10-29T00:15:58.299Z [info] akka.management.cluster.bootstrap.LowestAddressJoinDecider [sourceThread=application-akka.actor.default-dispatcher-3, akkaTimestamp=00:15:58.299UTC, akkaSource=LowestAddressJoinDecider(akka://application), sourceActorSystem=application] - Discovered [0] contact points, confirmed [0], which is less than the required [2], retrying
2019-10-29T00:15:58.599Z [warn] akka.cluster.sharding.ShardRegion [sourceThread=application-akka.actor.default-dispatcher-4, akkaTimestamp=00:15:58.597UTC, akkaSource=akka.tcp://application#192.168.0.34:2552/system/sharding/kafkaProducer-greetings, sourceActorSystem=application] - kafkaProducer-greetings: No coordinator found to register. Probably, no seed-nodes configured and manual cluster join not performed? Total [1] buffered messages.
I use Akka 2.5.25 and default configurations except the ones I specified above. E.g. I see the following logs that might be of relevance after running the service:
2019-10-29T00:15:44.987Z [info] akka.remote.Remoting [sourceThread=main, akkaTimestamp=00:15:44.987UTC, akkaSource=akka.remote.Remoting, sourceActorSystem=application] - Remoting now listens on addresses: [akka.tcp://application#192.168.0.34:2552]
2019-10-29T00:15:45.276Z [info] akka.cluster.Cluster(akka://application) [sourceThread=application-akka.actor.default-dispatcher-2, akkaSource=akka.cluster.Cluster(akka://application), sourceActorSystem=application, akkaTimestamp=00:15:45.275UTC] - Cluster Node [akka.tcp://application#192.168.0.34:2552] - No seed-nodes configured, manual cluster join required, see https://doc.akka.io/docs/akka/current/cluster-usage.html#joining-to-seed-nodes
2019-10-29T00:15:46.411Z [info] akka.management.cluster.bootstrap.ClusterBootstrap [sourceThread=main, akkaTimestamp=00:15:46.411UTC, akkaSource=ClusterBootstrap(akka://application), sourceActorSystem=application] - Using self contact point address: http://192.168.0.34:8558
2019-10-29T00:15:48.164Z [info] akka.management.scaladsl.AkkaManagement [sourceThread=application-akka.actor.default-dispatcher-24, akkaSource=AkkaManagement(akka://application), sourceActorSystem=application, akkaTimestamp=00:15:48.163UTC] - Bound Akka Management (HTTP) endpoint to: 192.168.0.34:8558
2019-10-29T00:15:48.286Z [info] akka.management.cluster.bootstrap.internal.BootstrapCoordinator [sourceThread=application-akka.actor.default-dispatcher-24, akkaSource=akka.tcp://application#192.168.0.34:2552/system/bootstrapCoordinator, sourceActorSystem=application, akkaTimestamp=00:15:48.285UTC] - Locating service members. Using discovery [akka.discovery.aggregate.AggregateServiceDiscovery], join decider [akka.management.cluster.bootstrap.LowestAddressJoinDecider]
2019-10-29T00:15:48.772Z [info] play.core.server.AkkaHttpServer [] - Listening for HTTP on /0:0:0:0:0:0:0:0:9000
So, I think there is a mismatch between the ports but I couldn't figure out how to fix it. Thanks for your help.
It seems the problem was a missing DNS server in the local settings and the fact that Lagom itself does not provide a DNS server
as stated by #tim-moore at Lightbend forum.

ejabberd clustering problems and solutions

Setup Details
2 ejabberd nodes with postgresql as database (OS : Ubuntu 16.04)
Trying to do clustering of two ejabberd as mentioned in
https://docs.ejabberd.im/admin/guide/clustering/
After starting the master node the following steps have been performed on the slave node
copy .erlang.cookie to the slave node
copy ejabbed.yml from master to slave.
slave started successfully but shows the below error.
=====Error=========
Eshell V9.2 (abort with ^G)
(ejabberd#gim-Veriton-M6650G)1> 18:29:41.856 [notice] Changed loghwm of /usr/local/var/log/ejabberd/error.log to 100
18:29:41.856 [notice] Changed loghwm of /usr/local/var/log/ejabberd/ejabberd.log to 100
18:29:41.857 [info] Application lager started on node 'ejabberd#gim-Veriton-M6650G'
18:29:41.860 [info] Application crypto started on node 'ejabberd#gim-Veriton-M6650G'
18:29:41.865 [info] Application sasl started on node 'ejabberd#gim-Veriton-M6650G'
18:29:41.871 [info] Application asn1 started on node 'ejabberd#gim-Veriton-M6650G'
18:29:41.871 [info] Application public_key started on node 'ejabberd#gim-Veriton-M6650G'
18:29:41.880 [info] Application ssl started on node 'ejabberd#gim-Veriton-M6650G'
18:29:41.881 [info] Application p1_utils started on node 'ejabberd#gim-Veriton-M6650G'
18:29:41.883 [info] Application fast_yaml started on node 'ejabberd#gim-Veriton-M6650G'
18:29:41.888 [info] Application fast_tls started on node 'ejabberd#gim-Veriton-M6650G'
18:29:41.892 [info] Application fast_xml started on node 'ejabberd#gim-Veriton-M6650G'
18:29:41.895 [info] Application stringprep started on node 'ejabberd#gim-Veriton-M6650G'
18:29:41.899 [info] Application xmpp started on node 'ejabberd#gim-Veriton-M6650G'
18:29:41.903 [info] Application cache_tab started on node 'ejabberd#gim-Veriton-M6650G'
18:29:41.910 [info] Application eimp started on node 'ejabberd#gim-Veriton-M6650G'
18:29:41.910 [info] Loading configuration from /usr/local/etc/ejabberd/ejabberd.yml
18:29:41.913 [error] CRASH REPORT Process <0.67.0> with 0 neighbours exited with reason: no case clause matching <<>> in ejabberd_config:get_config_option_key/2 line 473 in application_master:init/4 line 134
18:29:41.913 [info] Application ejabberd exited with reason: no case clause matching <<>> in ejabberd_config:get_config_option_key/2 line 473
(ejabberd#gim-Veriton-M6650G)1>
I've tried re creating mnesia DB also but didn't help.
ejabberdctl status shows ejabberd is not running in that node
Can some oe please look into the issue and help.
Finally I found the solution to the problem
The issue is with the node name as the node name of the master ia FQ name
but the slave node's name is without a domain.
Also added both the node names in the /etc/hosts file
For ejabberd clustering ,Please refer the below steps.
Before starting , configure proper entries in the /etc/hosts files of both nodes.
ie the nodes should resolve each other using their host names.
set ejaberd node name in ejabberd.cfg file , both the nodes should have different node names.
1.cofigure ejabberd in one master node with a proper node name (either a FQDN or just a name of your convenience)
2.Configure slave node with the same config as that of master ie. bot the nodes should have the same configuration in ejabberd.yml file)
3.copy erlang.cookie from master node to slave and the ejabberd user should be ale to read the cookie file.
4.Start the master node in live mode (ejabberdctl live )
5.Start slave node in live mode
6.Check the cookie value in erlang console of both the nodes using the command 'erlang:get_cookie().' , both the nodes should have the same value.
7.If bot the nodes have same value then execute "ejabberdctl --not-timeout join_cluser ejabberd#nodename" in the slave.
change ejabberd#nodename according to your environment.
In my case I ran ejabberd with 'ejabberd' user with node name as ejabberd#cluster-node1 (If you want you can use a FQDN also like ejabberd#example.com)
8.If the abode command executed without any error then the nodes are in cluster
9.Confirm the cluster in any of the erlang console using the command mnesia:info(). here you will get the node details in "running_db_nodes"
10.Hurrayyyy you are done...
For load balancing the cluster you can use HAProxy
Please refer https://blog.onefellow.com/post/76702632637/haproxy-and-ejabberd for details
I've not done load balancing using any hardware load balancer , need to check on that
If anyone have done that please do post here ..

Akka Singleton Cluster: resolveOnce of a worker by master fails after restart

I am using Akka Cluster 2.4.3 and trying to setup a simple cluster in my machine to understand its working better. I have a singleton cluster with remoting enabled with primary and standby master and one worker node. Each of these 3 run in separate JVMs
Things work fine when all the nodes are started the first time. If I kill and restart the worker, I see following issues happening
Restart Worker
When the worker comes back after restart, the master on receiving MemberUp event tries to resolve for the actorRef from the member address the following way
context.actorSelection(member.address.toString).resolveOne(15 seconds)
This fails with an exception saying ActorNotFound. This works with no problem when all the nodes are coming up for the first time in the cluster.
Restart worker again
This time, the worker comes up with the following message
[WARN] [04/15/2016 18:24:24.991] [clustersystem-akka.remote.default-remote-dispatcher-5] [akka.remote.Remoting] Tried to associate with unreachable remote address [akka.tcp://clustersystem#host1:2551]. Address is now gated for 5000 ms, all messages to this address will be delivered to dead letters. Reason: [The remote system has quarantined this system. No further associations to the remote system are possible until this system is restarted.]
Restart worker again
This time the resolveOne on a MemberUp event works.
I am having a bit of difficulty in understanding what is happening here, I have looked into the docs but I did not find anything that will help me in there.
application.conf
akka {
actor {
provider = "akka.cluster.ClusterActorRefProvider"
}
remote {
enabled-transports = ["akka.remote.netty.tcp"]
}
log-dead-letters = off
jvm-exit-on-fatal-error = on
loglevel = "DEBUG"
remote {
log-remote-lifecycle-events = off
netty.tcp {
hostname = "host1"
port = 0
}
}
cluster {
seed-nodes = [
"akka.tcp://clustersystem#host1:2551",
"akka.tcp://clustersystem#host1:2552"]
auto-down-unreachable-after = 10s
}
extensions = ["akka.cluster.metrics.ClusterMetricsExtension"]
}
I start master nodes at ports 2551 and 2552 (provide the ports as command line args) and I start the worker on port 3551

How debug akka association porcess?

Here is a scenario:
I have packaged scala project with spray into jar file.
Launch jar file on RedHat 6.5 on Virtual Box (ip - 192.168.1.38)
Launch jar file on RedHat 6.5 on Virtual Box (ip - 192.168.1.41)
Everything works locally - I can send REST request to each virtual machine and get response.
Problem
Akka systems can not became to cluster. I run 192.168.1.38 with default settings, but 192.168.1.41 have an additional property - akka.cluster.seed-nodes which is set to akka.tcp://mySystem#192.168.1.38:2551. So I get:
[WARN] [12/09/2014 17:10:24.043] [mySystem-akka.remote.default-remote-dispatcher-8] [akka.tcp://mySystem#192.168.1.41:2551/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FmySystem%40192.168.1.38%3A2551-0] Association with remote system [akka.tcp://mySystem#192.168.1.38:2551] has failed, address is now gated for [5000] ms. Reason is: [Association failed with [akka.tcp://mySystem#192.168.1.38:2551]].
No other errors or warning. Also how can I test akka association or print debug akka association settings?
Also can linux settings influence to akka association?
Most probably iptables is blocking particular port, if it's your test configuration just disable iptables.
service iptables save
service iptables stop
chkconfig iptables off
service ip6tables save
service ip6tables stop
chkconfig ip6tables off
If it will not help try to check you SELinux configuration using command getenforce and the same for test purposes you can completely disable it. SELinux manual
In case of your application.conf, try using following configuration for each node:
akka {
log-dead-letters = on
loglevel = "debug"
actor
{
provider = "akka.cluster.ClusterActorRefProvider"
}
extensions = ["akka.contrib.pattern.ClusterReceptionistExtension"]
remote {
log-remote-lifecycle-events = off
netty.tcp {
port = 6001
}
}
cluster {
seed-nodes = [
"akka.tcp://ActorSystem#192.168.1.38:6001",
"akka.tcp://ActorSystem#192.168.1.41:6001"
]
auto-down-unreachable-after = 10s
}
}
All the logs related to the cluster nodes are logged as info but having debug log level in test environment is in general good idea.
When the second, node will join the cluster, you should notice following log:
INFO [ActorSystem-akka.actor.default-dispatcher-4] [Cluster(akka://ActorSystem)] - Cluster Node [akka.tcp://ActorSystem#10.0.1.41:6001] - Marking node(s) as REACHABLE [Member(address = akka.tcp://ActorSystem#10.0.1.41:6001, status = Up)]
Cluster state could be also monitored using jmx akka.Cluster MXBean
{ "self-address": "akka.tcp://ActorSystem#10.0.1.82:6001", "members": [ { "address": "akka.tcp://ActorSystem#10.0.1.82:6001", "status": "Up" } ], "unreachable": [ ] }

akka cluster seed nodes give error: dropping message for non-local recipient

I'm trying to create a basic akka cluster on a Win 7 machine from this documentation:
http://doc.akka.io/docs/akka/snapshot/scala/cluster-usage.html
and I'm getting an error when I run the seed nodes (more on them below)
AdriansClusterSystem-akka.actor.default-dispa tcher-16]
[akka://AdriansClusterSystem/system/endpointManager/reliableEndpointWr
iter-akka.tcp%3A%2F%2FAdriansClusterSystem%40127.0.0.1%3A2552-3/endpointWriter]
dropping message [class akka.actor.SelectChildName] for non-local
recipient [Act or[akka.tcp://ClusterSystem#127.0.0.1:2552/]] arriving
at [akka.tcp://ClusterSys tem#127.0.0.1:2552] inbound addresses are
[akka.tcp://AdriansClusterSystem#127.0 .0.1:2552]
Question:
Why am I getting this error? Did I miss something from the akka documentation?
My .conf file:
I added this extra line *To the file listed at the URL above *
enabled-transports = ["akka.remote.netty.tcp"]
akka {
actor {
provider = "akka.cluster.ClusterActorRefProvider"
}
remote {
enabled-transports = ["akka.remote.netty.tcp"] <--added this from remoting
log-remote-lifecycle-events = off
netty.tcp {
hostname = "127.0.0.1"
port = 0
}
}
cluster {
seed-nodes = [
"akka.tcp://ClusterSystem#127.0.0.1:2551",
"akka.tcp://ClusterSystem#127.0.0.1:2552"]
auto-down = on
}
}
I start the 2 nodes, each in different sbt windows
run-main sample.cluster.simple.SimpleClusterApp 2551
run-main sample.cluster.simple.SimpleClusterApp 2552
Both of these start up fine then repeatedly show an ERROR message:
mybuild:-:0.0.1-SNAPSHOT>`run-main sample.cluster.simple.SimpleClusterApp 2552`
[warn] Credentials file C:\Users\amocanu\.ivy2\.credentials does not exist <-- ?
[info] Running sample.cluster.simple.SimpleClusterApp 2552
args[0]= 2552
[INFO] [07/31/2013 10:50:00.397] [run-main] [Remoting] Starting remoting
[INFO] [07/31/2013 10:50:00.661] [run-main] [Remoting] Remoting started; listeni
ng on addresses :[akka.tcp://AdriansClusterSystem#127.0.0.1:2552]
[INFO] [07/31/2013 10:50:00.710] [run-main] [Cluster(akka://AdriansClusterSystem
)] Cluster Node [akka.tcp://AdriansClusterSystem#127.0.0.1:2552] - Starting up..
.
[INFO] [07/31/2013 10:50:00.823] [run-main] [Cluster(akka://AdriansClusterSystem
)] Cluster Node [akka.tcp://AdriansClusterSystem#127.0.0.1:2552] - Registered cl
uster JMX MBean [akka:type=Cluster]
[INFO] [07/31/2013 10:50:00.823] [run-main] [Cluster(akka://AdriansClusterSystem
)] Cluster Node [akka.tcp://AdriansClusterSystem#127.0.0.1:2552] - Started up su
ccessfully
[INFO] [07/31/2013 10:50:00.868] [AdriansClusterSystem-akka.actor.default-dispat
cher-2] [Cluster(akka://AdriansClusterSystem)] Cluster Node [akka.tcp://AdriansC
lusterSystem#127.0.0.1:2552] - Metrics will be retreived from MBeans, and may be
incorrect on some platforms. To increase metric accuracy add the 'sigar.jar' to
the classpath and the appropriate platform-specific native libary to 'java.libr
ary.path'. Reason: java.lang.ClassNotFoundException: org.hyperic.sigar.Sigar
[INFO] [07/31/2013 10:50:00.874] [AdriansClusterSystem-akka.actor.default-dispat
cher-2] [Cluster(akka://AdriansClusterSystem)] Cluster Node [akka.tcp://AdriansC
lusterSystem#127.0.0.1:2552] - Metrics collection has started successfully
[INFO] [07/31/2013 10:50:00.883] [AdriansClusterSystem-akka.actor.default-dispat
cher-13] [akka://AdriansClusterSystem/user/clusterListener] Current members:
[ERROR] [07/31/2013 10:50:01.003] [AdriansClusterSystem-akka.actor.default-dispa
tcher-3] [akka://AdriansClusterSystem/system/endpointManager/reliableEndpointWri
ter-akka.tcp%3A%2F%2FAdriansClusterSystem%40127.0.0.1%3A2551-0/endpointWriter] d
ropping message [class akka.actor.SelectChildName] for non-local recipient [Acto
r[akka.tcp://ClusterSystem#127.0.0.1:2552/]] arriving at [akka.tcp://ClusterSyst
em#127.0.0.1:2552] inbound addresses are [akka.tcp://AdriansClusterSystem#127.0.
0.1:2552]
[ERROR] [07/31/2013 10:50:01.009] [AdriansClusterSystem-akka.actor.default-dispa
tcher-16] [akka://AdriansClusterSystem/system/endpointManager/reliableEndpointWr
iter-akka.tcp%3A%2F%2FAdriansClusterSystem%40127.0.0.1%3A2552-3/endpointWriter]
dropping message [class akka.actor.SelectChildName] for non-local recipient [Act
or[akka.tcp://ClusterSystem#127.0.0.1:2552/]] arriving at [akka.tcp://ClusterSys
tem#127.0.0.1:2552] inbound addresses are [akka.tcp://AdriansClusterSystem#127.0
.0.1:2552]
If now I do
run-main sample.cluster.simple.SimpleClusterApp
which is supposed to choose a random port and run a seed node on, it starts of well just as the other 2 seed nodes, then shows a class not found exception as INFO and no current members
[INFO] [07/31/2013 11:19:36.612] [AdriansClusterSystem-akka.actor.default-dispat
cher-3] [Cluster(akka://AdriansClusterSystem)] Cluster Node [akka.tcp://AdriansC
lusterSystem#127.0.0.1:54824] - Metrics will be retreived from MBeans, and may b
e incorrect on some platforms. To increase metric accuracy add the 'sigar.jar' t
o the classpath and the appropriate platform-specific native libary to 'java.lib
rary.path'. Reason: java.lang.ClassNotFoundException: org.hyperic.sigar.Sigar
[INFO] [07/31/2013 11:19:36.619] [AdriansClusterSystem-akka.actor.default-dispat
cher-3] [Cluster(akka://AdriansClusterSystem)] Cluster Node [akka.tcp://AdriansC
lusterSystem#127.0.0.1:54824] - Metrics collection has started successfully
[INFO] [07/31/2013 11:19:36.633] [AdriansClusterSystem-akka.actor.default-dispat
cher-12] [akka://AdriansClusterSystem/user/clusterListener] Current members:
Yup it just hangs there and I have to close the sbt window to terminate it.
It looks like your seed nodes are using ClusterSystem as the actor system name but according to your logs you are using AdriansClusterSystem as your actor system name. Try changing the seed nodes to:
seed-nodes = [
"akka.tcp://AdriansClusterSystem#127.0.0.1:2551",
"akka.tcp://AdriansClusterSystem#127.0.0.1:2552"]
For the benefit of searchers...
Firstly, check the accepted answer from #cmbaxter.
However, if that fails:
Run your cluster and copy the address of the seed node e.g. akka.tcp://ClusterSystem#localhost:8092/system/endpointManager/...
Now check the address in the error e.g. Dropping message [Akka.Actor.ActorSelectionMessage] for non-local recipient [[akka.tcp://ClusterSystem#127.0.0.1:8092/]]
In my case, ClusterSystem was set up on localhost, but the calling code was calling 127.0.0.1.
Setting client and cluster (including seed-nodes) to the same address fixed it (I set both to 127.0.0.1)