npgsql/Npgsql — pull request #178 by tenor (2014-03-02 00:20:21+00:00)
Title: Distribute available connectors in an orderly first come, first served manner.

The current connection pool doesn't perform well in a high demand environment because the connectors are not distributed in an orderly fashion.

In the existing logic, when a request for a connector comes in and there is no available connector, it waits for a second and tries again until it gets one or times out.
This is okay when you have a small request rate or when you have a large pool of connectors but in a situation when you have a small pool of connectors and/or a large number of requests, what ends up happening is that there is a lot of contention for connectors. A request might come in and wait for a free connector only to be "cut in line" by another request which just happens to grab the connector while the older request was sleeping. The older request may very well end up not getting a connection and fail.

If you take a web application that performs five database calls in one request, the chances for one database call to fail in such an environment is high. And if one DB call fails. the entire web request fails.
I have a web application that suffered from this issue until I made this change.

A more scalable solution is to distribute the connectors to requests on a first come, first served basis. This will ensure that every request is guaranteed to get their turn or time out in a more even manner.

This pull request addresses two issues:

1. Incoming requests for connectors are queued and processed as the connectors become available.
2. Reduces the sleep time from 1 second to 10 ms. This will not task the CPU any more than it does because the requests are processed one by one.

The unit test all pass after applying this change. However, If you do a "Run All" unit tests, you'll see a bunch of them failing. if you run them one by one, they all pass (except TestOutParameter2 which depends on another test). I believe the reason why the tests fail when they run in bulk is that the tests run faster than usual and run into port exhaustion issues.

Here's a sample test error:

```
Result Message:
SetUp : Npgsql.NpgsqlException : Failed to establish a connection to '127.0.0.1'.
----> System.Net.Sockets.SocketException : No connection could be made because the target machine actively refused it 127.0.0.1:44444
```

It occurs in the Npgsql.NpgsqlConnector.Open() method.`