5

After configuring bind-hostname and bind-port in application.conf, as specified by the Akka FAQ, and bringing up the cluster, I'm receiving an error:

[ERROR] [07/09/2015 19:54:24.132] [default-akka.remote.default-remote-dispatcher-20] 
[akka.tcp://default@54.175.105.30:2552/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2Fdefault%4054.175.105.30%3A2552-757/endpointWriter]
dropping message [class akka.actor.ActorSelectionMessage] 
for non-local recipient[Actor[akka.tcp://default@54.175.105.30:32810/]] 
arriving at [akka.tcp://default@54.175.105.30:32810] 
inbound addresses are [akka.tcp://default@54.175.105.30:2552]

What this seems to say is that the actor has received a message destined for port 32810 (the external port) but its dropping it because the internal port (2552) doesn't match.

The relevant portions of the file are:

  hostname = 54.175.105.30
  port = 32810

  bind-hostname = 172.17.0.44
  bind-port = 2552

I've tried this on 2.4-M1, 2.4-M2, and 2.4-SNAPSHOT, all with the same effect.

Has anyone else encountered this before? Any suggestions?

edit: This actor system is running in ECS in docker containers. The docker container configuration is set to forward from the ephemeral range to 2552 on the container's private IP. ECS is successfully mapping the hostname:port to bind-hosname:bind-port. The actor is successfully running and binding to the local bind-hostname and bind-port, but is dropping messages and emitting the error described above.

babbitt
  • 871
  • 11
  • 22
  • just curious, you were able to set `bind-hostname` to the bridge instead of `0.0.0.0`? by setting network type to `host`? – Matt Mar 15 '17 at 19:10

2 Answers2

6

bind-* configuration settings are meant to be used in situations when Akka nodes are started behind NAT (or in docker containers). Have you configured address translation from hostname:port to bind-hostname:bind-port?

In your particular configuration, when you do

ctx.actorSelection("akka.tcp://default@54.175.105.30:32810/user/actor") ! "Hi"

then someone at 54.175.105.30 should be listening for TCP port 32810 and port forwarding to 172.17.0.44:2552. The actor system should be running with your provided configuration at 172.17.0.44:2552. Is this the case?

Also you have to configure this for every node that is behind a NAT, because connections between Actor Systems are peer to peer.

dvim
  • 2,223
  • 1
  • 17
  • 17
  • If you look at the error message the strange thing seems to be this address/port combination: `54.175.105.30:2552` which combines the `hostname` with the `bind-port`. How would that happen? – jrudolph Jul 14 '15 at 06:57
  • Yes, in this case we're using docker on ECS and dynamically configuring the application.conf using AWS/ECS introspection. The IP addresses and ports are correct, and ports are being forwarded by docker from the ephemeral range (32810 in this case) to the container port (2552 in this case). Every docker container that starts in ECS runs the introspection/application.conf configuration script to configure itself and populate its seeds. – babbitt Jul 14 '15 at 16:50
  • @jrudolph: that's my question. It looks like the actor is looking for messages coming in on its bind-hostname:port, when it needs to look on its bind-hostname:bind-port. – babbitt Jul 15 '15 at 12:20
1

This was due to a misconfiguration on my end. Some boilerplate code was remaining that was overriding the bind-port.

babbitt
  • 871
  • 11
  • 22
  • any chance you could share your methodology? I'm trying to use the out of the box service discovery from amazon DNS (see blog post) that maps SRV records to the services. – Matt Mar 14 '17 at 22:53