Association failed - Connection refused error

Hi,
I am facing an issue of fail to connect to the seed node.
I am seeing the following message:

Cluster Node [akka.tcp://uncompress-adc-service@192.168.65.3:2552] - Started up successfully

Above, I am unable to figure out why the IP address 192.168.65.3 is picked instead of “127.0.0.1” supplied in the application.conf

Later I see the following error in log

Remote connection to [null] failed with java.net.ConnectException: Connection refused: localhost/127.0.0.1:2552

After that I see the following log

 Reason: [Association failed with [akka.tcp://uncompress-adc-service@localhost:2552]] Caused by: [ja
va.net.ConnectException: Connection refused: localhost/127.0.0.1:2552]

This is my application.conf entry for seed node.

application.akka.container.address = "localhost"

        seed-nodes = [
            "akka.tcp://"${application.uncompress.servicename}"@"${application.akka.container.address}":2552"
            ]

However if I change the seed node configuration to as below, i do not get any error.

"akka.tcp://"${application.uncompress.servicename}"@192.168.65.3:2552"

[Edit : 21/11/2019]
Here are some logs from the during startup.

2019-11-21 08:35:08.095 INFO  akka.remote.Remoting main akka.remote.Remoting - Starting remoting
2019-11-21 08:35:08.378 INFO  akka.remote.Remoting main akka.remote.Remoting - Remoting started; listening on addresses :[akka.tcp://uncompress-adc-service@192.168.65.3:2552]
2019-11-21 08:35:08.384 INFO  akka.remote.Remoting main akka.remote.Remoting - Remoting now listens on addresses: [akka.tcp://uncompress-adc-service@192.168.65.3:2552]
2019-11-21 08:35:08.423 INFO  a.c.Cluster(akka://uncompress-adc-service) main akka.cluster.Cluster(akka://uncompress-adc-service) - Cluster Node [akka.tcp://uncompress-adc-service@192.168.65.3:2552] - Starting up, Akka version [2.6.0-M5] ...
2019-11-21 08:35:08.631 INFO  a.c.Cluster(akka://uncompress-adc-service) main akka.cluster.Cluster(akka://uncompress-adc-service) - Cluster Node [akka.tcp://uncompress-adc-service@192.168.65.3:2552] - Registered cluster JMX MBean [akka:type=Cluster
]
2019-11-21 08:35:08.632 INFO  a.c.Cluster(akka://uncompress-adc-service) main akka.cluster.Cluster(akka://uncompress-adc-service) - Cluster Node [akka.tcp://uncompress-adc-service@192.168.65.3:2552] - Started up successfully
2019-11-21 08:35:08.745 WARN  akka.cluster.AutoDown uncompress-adc-service-akka.actor.default-dispatcher-6 akka.tcp://uncompress-adc-service@192.168.65.3:2552/system/cluster/core/daemon/downingProvider - Don't use auto-down feature of Akka Cluster
in production. See 'Auto-downing (DO NOT USE)' section of Akka Cluster documentation.
2019-11-21 08:35:09.217 WARN  a.r.transport.netty.NettyTransport New I/O boss #3 NettyTransport(akka://uncompress-adc-service) - Remote connection to [null] failed with java.net.ConnectException: Connection refused: /127.0.0.1:2552

I am seeing that the first two logs coming from start() method in file https://github.com/akka/akka/blob/master/akka-remote/src/main/scala/akka/remote/Remoting.scala
Unfortunately I do not know scala to dig deeper.

Any idea why this happens(192.168.65.3(eth0) is used instead of 127.0.0.1(lo))?Any pointers to resolve this issue?

Thanks in advance
Naveena

I’d recommend that you update to Akka 2.6.0, instead of M5.

Then make sure you define the akka.remote.classic.netty.tcp.hostname

Or even better switch to Artery tcp, which is the default choice in Akka 2.6.0.

Take a look at migration guide.

Thanks Patrik for your response!
I did not configure any explicit version for Akka. I think Lagom version maps to corresponding Akka version. I tried with Lagom 1.6.0(for which pom file showed a bunch of red flags) but looks like there is only 1.6.0-RC2 version available. This also gave the same problem. Finally I moved to earlier version of Lagom(1.5.4) and I could provide the address 127.0.0.1 and it is picked properly. Is it that only Lagom GA release would handle this IP address the way how it supposed and other versions(say M and RC) use eth0 IP address?

Thanks again for all your help
Naveena