Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Akka.IO and Azure WebApp connectivity issue #3679
Original issue: remoting doesn't work properly with Azure WebApps. I've reported that on Gitter. In a nutshell: when target is up and source is connecting it goes through and stays that way until connection is interrupted, for example, if I manually restart the Azure WebApp it tries to connect again, but this time once source -> target connection is established, target for some reason decides to also connect to the source, i.e. target -> source. And this fails, endpoint is gated. This probably works with ASE environments, but for regular mortals it is not an option. Because docs mention for the remoting to work both endpoints have to be reachable. A heart breaking decision, but had to let the remoting go :(
Another take: I wanted to keep Akka and actors. Spend about a week and now have a client-server solution based on Akka.IO. It is one way: several sources and concurrently for each source an .Ask() is invoked.
Problem: aforementioned implementation works great locally and over LAN. Fails when app is published to Azure WebApp. It is known that this PaaS environment has its own specific requirements for remoting. It took a bit of googling and digging the documentation, but solution is there and it is purely config based which is nice. However, because I can't use remoting any longer, I need to be able to configure Akka.IO in the same way, but there doesn't seem to be an easy solution.
Current workaround: well, I suspected I need to disable the IPv6, same as for remoting. Removed the nuget package from projects, downloaded the sources for 1.3.10 and modified the
basically added IPv4 as the address family, referenced a local release build of Akka, republished and it worked.
Given that, I'm proposing to make the address family configurable. Not a sockets expert, but it seems there are three configuration options in this case:
which basically can be an
@snekbaev yeah, this sound right - Azure's PaaS environments have, for reasons that are inexplicable, have been unable to adopt IPv6 for years.
If you want to adjust the API for making the IPFamily configurable, similar to how we do it for Akka.Remote, I'm sure we'd be open to supporting that.
Unlike the dotnetty configuration, this one is a bit different. Family can't be enforced because as mentioned earlier, current listening socket already enforces it, however, client socket by default doesn't.
Also added some comments to clarify that if outgoing socket is forced to IPv4 then DNS needs to be forced to IPv4 as well, otherwise if DnsEndPoint's primary address/fallback address or IPEndPoint's address ends up being IPv6, then exception is thrown during socket creation.
These changes are obviously opt-in.