fix OOM issue. In some cases, the vertx ClientConnection and it's refered NioSocketChannel is actually unvailable but it still kept in the connection pool. It can accept client requests and add them to its internal queue for later consuming. However the consuming will never happen because it's the zombie NioSocketChannel throw out exception only and then the connection is returned to the pool to accept annother request. There is no chance to remove request from the internal queue. So the connection holds more and more requests. Since the connection can be reached by GC root so all it's refered connections are reachable too. That's the cause of OOM.

How to fix: there might be some other cases which leads the same issue so the best way to fix it is close the underlying channel whenever exception caught. And the connection will be released as well. Actually, the same fix was commited to eclipse/vert.x master branch already. The adsk fork is a little out-dated.
Merge pull request #3 from wangjunbo924/master

fix OOM issue on abus server
remove closed connections from pool to avoid potential memery leak.
Following is the detail of the issue for those who are interested in itJ

The issue happens when adapters respond a non-success http code.(Perhaps not all non-success code , but I’m sure 404 will 100% re-produce this issue) . In this case an closed connection will be referenced by the connection pool which leads to: 1) the connection pool holds more and more closed connections. It’s a memory leak. The memory keeps increasing.   2) every time a new request try to select a connection, it will iterate all connections. As the pool size increases, more and more CPU time are wasted.   3) By default a closed connection won’t be used. However, under high load, it’s easily the count of in-use connections reaches the threshold: 10 by default. Then vert.x will try to assign an closed connection to request. And since its’ closed the request will try to pick up another connecton(The first one can be released now).  Probably vertx assign another closed connection. It’s an infinite loop which cause “StackOverFlowError”.
Merge pull request #4 from wangjunbo924/master

remove closed connections from pool to avoid potential memory leak.
Use new version to incude Junbo's fixes to closed conenctions causing infinite recursion.
revert hazelcast version
GO back to 2.5.1 for hazelcast - it was a mistake when I changed it.