<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 20, 2014 at 5:34 AM, Peter Rabbitson <span dir="ltr"><<a href="mailto:rabbit+dbic@rabbit.us" target="_blank">rabbit+dbic@rabbit.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/10/2014 06:37 AM, Bill Moseley wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Thu, Oct 9, 2014 at 6:32 PM, Ben Tilly <<a href="mailto:btilly@gmail.com" target="_blank">btilly@gmail.com</a><br></span><span class="">
<mailto:<a href="mailto:btilly@gmail.com" target="_blank">btilly@gmail.com</a>>> wrote:<br>
<br>
The obvious thing to try is to use the alarm() function to send<br>
yourself a signal and set a signal handler that will just die to<br>
escape. But this is unlikely to work due to safe signals. Search for<br>
"Safe Signals" in perldoc perlipc for details. It will also show you<br>
how to use the POSIX module to set a signal handler that can work<br>
despite that.<br>
<br>
<br>
But where? Set storage_type and override/wrap the private method<br>
_connect or _populate_dbh? I'm wondering what's a good place to hook into.<br>
<br>
</span></blockquote>
<br>
Hi Bill<br>
<br>
I am going through my backlog, wondering if you still need help with this or you figured out a way forward?</blockquote><div><br></div><div><br></div><div>Hi Peter,</div><div><br></div><div>No, I never followed up and made any code changes. </div><div><br></div><div>I think when I posted this we had just moved to configuring a single slave in DBIC which talked to HA Proxy configured to load balance a number of pg_bouncer instances in front of Postgresql databases. We likely had some config hiccup where HA Proxy accepted the connection yet there was no pg_bouncer (or Postgresql?) connection available and it just blocked.</div><div><br></div><div>Have not had problems like that since then, but obviously having a database connection block for a long time brings a busy site to its knees.</div><div><br></div><div>Of course, timing out and falling back to the master may not result in better results if the master cannot support the load alone. But, better to return an error quickly than blocking.</div><div><br></div><div><br></div><div>I'm not sure it makes sense to have the timeout in DBIC -- if it was then maybe just in the _ping method. But, in general how long to wait depends on what is expected from the request which is only known at the app level.</div><div><br></div><div><br></div></div><div><br></div>-- <br><div class="gmail_signature">Bill Moseley<br><a href="mailto:moseley@hank.org" target="_blank">moseley@hank.org</a></div>
</div></div>