The following deadlock scenario exists:

1. When Play dev mode first starts, if many requests come through at once, and they attempt to calculate the remote address for the request.
2. The forwarded header handler will be loaded from the application. This is a lazy val, so only the first thread will load it, the rest will block.
3. These blocking threads, if they are running on the Akka thread pool, may exhaust the Akka thread pool.
4. The thread loading the forwarded header handler must get the application from DevModeStart, which delegates getting the application to the Akka thread pool.
5. Since the Akka thread pool may be exhausted due to threads waiting for the forwarded header handler lazy val, this will deadlock.

Potential solutions include:

• Don't get the current application on a another thread, only delegate to another thread if it needs to be loaded.
• Don't delegate to another thread at all - I don't see what's wrong with loading an application on the Netty thread.
• Redesign the way the forwarded header handler works so that it doesn't need to go through the ApplicationProvider to get the application, it uses an already loaded application.
• Don't use a lazy val for the forwarded header handler, just cache in a non thread safe manner, the worst that could happen would be it has to be looked up out of the current application many times.