On Thu, 22 Jun 2017 20:25:40 -0400, Steven Schveighoffer wrote:

On 6/21/17 5:43 AM, Paolo Invernizzi wrote:

Vibe.d documentation about lockConnection states:

Note that, after retrieving a connection with lockConnection, the caller has to make sure that the connection is actually physically open and to reopen it if necessary. The ConnectionPool class has no knowledge of the internals of the connection objects.

Let's assume the pool is returning a TCP connection:

  • there's no method for 'reopening' it, so it's not possible.
  • there's no method to remove that 'closed' connection from the pool.

So, what I've to do with that closed pooled connection? What's the correct way to use a Connection Pool in that case?

Thanks

I don't think you would use a pool for such a setup. My use case is I
don't want to continuously negotiate an open connection with a MySQL
server, so I leave the connections open and just limit them to a certain
number.

A possibility is that the connection has been closed by the other side,
and that was what caused the fiber using it to release it back to the
pool. In that case, you need to open it again.

If your connection type is a "use once" type, you wouldn't use a pool
for it. Of course, the limitation is based on your type -- surely it has
a socket handle internally that can be rebound to a new socket (so a
reopen is technically possible).

-Steve

The point is exactly this, if the pool returns a vibe.d TCPConnection, and the server just close it, there's no way to:

  • re-open it, there's not method for that in TCPConnection
  • inform the pool to just discard it from the pool, as it's closed, and not re-openable

Basically, if some of the pooled connection is closed, the pool suddenly become useless... or at least, as you pointed out, it's not usable with the TCPConnection.
In my opinion, at least a method to tell the pool to discard a pooled connection is needed, what do you think?

/Paolo