Akka Remoting not fully shutting down after test?

I’m building an application based on Akka Cluster Sharding, under Play 2.7 (and thus Akka 2.5), using Classic Akka for now. (I’ll switch to Akka Typed in due course, probably after we can upgrade to Play 2.8, but for now it’s easier to build it in Classic.)

That’s all working nicely – the problem is when I run my tests. I’m building some fairly realistic Play API-level tests, which involve instantiating and running the components and the application largely for real, feeding inputs into them, and then shutting them down and moving on to the next test. This is the way I normally test, and it generally works well.

In this case, it’s working well for the first test, but when I try to run the second I’m getting:

org.jboss.netty.channel.ChannelException: Failed to bind to: localhost/127.0.0.1:2552

So the cluster channel obviously isn’t shutting down at the end of the first test – but I don’t understand why not. I’m calling CoordinatedShutdownProvider().get.run at the end of each test, and that’s always done a good job of shutting Play down cleanly. It doesn’t seem to be releasing the remoting port, though.

Am I missing something? How do I tell the cluster to shut itself down properly, beyond what I’m already doing with CoordinatedShutdown?

I’m assuming you await for the invocation to CoordinatedShutrdown to complete.

Hmmm, are you sure that CoordinatedShutdownProvider is returning the CoordinatedShutdown instance for the running ActorSystem? Is it possible your test code starts an ActorSystem and then it also creates an Application with a different ActorSystem in it? :thinking:

1 Like

Heh – yes. I used to have a bug caused by not waiting for that, but that’s correct at this point.

Aha! Yes, that’s probably it. I had totally forgotten about that, but I have a separate system for the clustering. (Mostly because that was what I was told to do the first time I built a cluster, something like seven years ago, so it’s become habit – don’t know if that’s still considered best practice.)

I’ll try dealing with that – thanks!