On Mon, 26 Jun 2017 11:24:04 -0400, Steven Schveighoffer wrote:
On 6/26/17 8:58 AM, Paolo Invernizzi wrote:
On Thu, 22 Jun 2017 20:25:40 -0400, Steven Schveighoffer wrote:
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).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?It's not a terrible idea, but you could also just wrap the connection in
something that can recreate the TCPConnection, and then pool on that.I can see it being easier to deal with instructing the pool to discard
or reuse an instance than this.-Steve
Thanks Steven, that's a good idea.