Is there any hooks for .on('error') to remove a driver from the pool?

[mcavage]

Hi,

Great module - I didn't see it from briefly scanning your code: it's pretty common that with various drivers (especially stateful/long-lived ones), I'd want to have the pool auto-purge a client that emits an error event, so it can recreate another one to replace it. Is there a way to do that?

Thanks!
~Mark

[coopernurse]

hey there,

Yep, try using pool.destroy(obj) instead of pool.release(obj) - destroy()
will decrement the usage count on the resource and call
factory.destroy(obj) so you can attempt to close it.

does that help?

-- James

On Thu, Feb 2, 2012 at 11:30 AM, Mark Cavage <
reply@reply.github.com

wrote:

Hi,

Great module - I didn't see it from briefly scanning your code: it's
pretty common that with various drivers (especially stateful/long-lived
ones), I'd want to have the pool auto-purge a client that emits an error
event, so it can recreate another one to replace it. Is there a way to do
that?

Thanks!
~Mark

---

Reply to this email directly or view it on GitHub:
#31

James Cooper
http://blog.bitmechanic.com/

[mcavage]

Oh ok - so just do it "outside" of the pool. I was asking if pool could just manage this automatically (that would be a nice new feature).

[coopernurse]

ah.. yeah, I guess I'm open to it. Feel free to propose a design. Are
you asking for the pool to do a health check on acquire and/or release? Or
some other way?

-- James

On Thu, Feb 2, 2012 at 11:48 AM, Mark Cavage <
reply@reply.github.com

wrote:

Oh ok - so just do it "outside" of the pool. I was asking if pool could
just manage this automatically (that would be a nice new feature).

---

Reply to this email directly or view it on GitHub:
#31 (comment)

James Cooper
http://blog.bitmechanic.com/

[mcavage]

Well, I guess we could do that too (health check on acquire). I was actually thinking more of .on('error') it could go into a "destroy -> create". I dunno, maybe it's not worth it if it's wrapped outside of the pool. Because either way (health check or error-based), it does feel like you'd have to do retry/backoff, otherwise you could end up in a "spin" when the backend resource is out.

[coopernurse]

right, exactly. .on(error) seems similar to .destroy(obj) -- in either
case factory.create() will get called if all pool objects are in use.

DBCP for Java has health check hooks, so I'd be open to adding something
like that. In particular you could have removeIdle() execute the health
check hook on the factory (if defined).. Would that be useful for you? or
is that unrelated to your use case?

-- James

On Thu, Feb 2, 2012 at 11:54 AM, Mark Cavage <
reply@reply.github.com

wrote:

Well, I guess we could do that too (health check on acquire). I was
actually thinking more of .on('error') it could go into a "destroy ->
create". I dunno, maybe it's not worth it if it's wrapped outside of the
pool. Because either way (health check or error-based), it does feel like
you'd have to do retry/backoff, otherwise you could end up in a "spin" when
the backend resource is out.

---

Reply to this email directly or view it on GitHub:
#31 (comment)

James Cooper
http://blog.bitmechanic.com/

[mcavage]

Yeah I think a health check hook like jakarta's that's executed outside of my normal code flows would actually get me the same thing - so sold :)

[coopernurse]

Sweet. I'll keep this issue open as a placeholder. swamped a bit at the
moment

On Thu, Feb 2, 2012 at 12:53 PM, Mark Cavage <
reply@reply.github.com

wrote:

Yeah I think a health check hook like jakarta's that's executed outside of
my normal code flows would actually get me the same thing - so sold :)

---

Reply to this email directly or view it on GitHub:
#31 (comment)

James Cooper
http://blog.bitmechanic.com/

[sandfox]

Going to close due to age reasons. Feel free to re-open if this issue is still relevant anyone.