Problems :
      1) Connect blocks the selector. This causes other operations
(read/write ) queued on the selector to incur additional latency or
timeout. This is worse when you have data centers that are far away.
      2) ProtocolNegotiation request is done after the connection
establishment which blocks the selector in the same manner.
      3) If Exceptions are encountered while getting connections from
the queue they are ignored.

Solutions :
         The connection creation is async. Create method is modified to
createAsync and it takes in the pool object. for NIO the createAsync
triggers an async operation which checks in the connection when it is
ready. For Blocking connections the createAsync blocks, creates the
connection and checks in the connection to the pool before returning.
         As the connection creation is async now, exceptions are
remembered (for 5 seconds ) in the pool. When some thread asks for a
connection and if the exceptions are remembered they will get an
exception.
         There is no ordering in the way connections are handed out, one
thread can request a connection and before it could wait, other thread
could steal this connection. This is avoided to a certain extent by
instead of doing one blocking wait, the thread splits the blocking wait
in 2 half and creates connection if required. This should not be a
problem in the real world as when you reach steady state ( create
required number of connections) this can't happen.
           Upgrade the source compatibility from java 5 to 6.
Most of the code is written with the assumption of Java 6, I don't
believe you can run this code on Java 5. So the impact should be
minimal, but if it goes in Client V2 branch, it will get benefit of
additional testing.