Null weird problem when using tugboat within a Play app

[andypetrella]

Hello man.

Context

I got the below weird stuff blowing when I used this (cool!) project from within the SparkNotebook.

Env

It failed on several ubuntu boxes, the current one is

• Dell
• ubuntu 14.04lts
• 64b
• docker version

Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8
OS/Arch (client): linux/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8

Reproducible

To easily reproduce it, I created a slim play project showing it: https://github.com/andypetrella/tugboat-play.

git clone https://github.com/andypetrella/tugboat-play
cd tugboat-play
sbt run

Open url at http://localhost:9000/dockers.

xdg-open http://localhost:9000/dockers

Additional note

I have absolutely no issues when using tugboat from a simple and skinny SBT app (with only it as dependency).

So there is something fishy with the socket host (socket, ..., ???) resolution when it's done in a play env, I guess -- play is maybe hacking this? Dunno.
(my probably not worthy 2¢)

Exception

This stuff blows whenever a docker call is issued.

play.api.Application$$anon$1: Execution exception[[ConnectException: http://localhost/info]]
    at play.api.Application$class.handleError(Application.scala:296) ~[play_2.10-2.3.8.jar:2.3.8]
    at play.api.DefaultApplication.handleError(Application.scala:402) [play_2.10-2.3.8.jar:2.3.8]
    at play.core.server.netty.PlayDefaultUpstreamHandler$$anonfun$14$$anonfun$apply$1.applyOrElse(PlayDefaultUpstreamHandler.scala:205) [play_2.10-2.3.8.jar:2.3.8]
    at play.core.server.netty.PlayDefaultUpstreamHandler$$anonfun$14$$anonfun$apply$1.applyOrElse(PlayDefaultUpstreamHandler.scala:202) [play_2.10-2.3.8.jar:2.3.8]
    at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:33) [scala-library.jar:na]
Caused by: java.net.ConnectException: http://localhost/info
    at com.ning.http.client.providers.netty.NettyConnectListener.operationComplete(NettyConnectListener.java:103) ~[async-http-client-1.8.10.jar:na]
    at org.jboss.netty.channel.DefaultChannelFuture.notifyListener(DefaultChannelFuture.java:431) ~[netty-3.9.6.Final.jar:na]
    at org.jboss.netty.channel.DefaultChannelFuture.addListener(DefaultChannelFuture.java:145) ~[netty-3.9.6.Final.jar:na]
    at com.ning.http.client.providers.netty.NettyAsyncHttpProvider.doConnect(NettyAsyncHttpProvider.java:1138) ~[async-http-client-1.8.10.jar:na]
    at com.ning.http.client.providers.netty.NettyAsyncHttpProvider.execute(NettyAsyncHttpProvider.java:935) ~[async-http-client-1.8.10.jar:na]
Caused by: java.nio.channels.UnresolvedAddressException: null
    at sun.nio.ch.Net.checkAddress(Net.java:127) ~[na:1.7.0_45]
    at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:640) ~[na:1.7.0_45]
    at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink.connect(NioClientSocketPipelineSink.java:108) ~[netty-3.9.6.Final.jar:na]
    at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink.eventSunk(NioClientSocketPipelineSink.java:70) ~[netty-3.9.6.Final.jar:na]
    at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:779) ~[netty-3.9.6.Final.jar:na]

Thank

you

[andypetrella]

okay looking further, the bugs #12 and #13 looks the same :-)