[Dbix-class] Connection timeouts?

[Bill Moseley]

On Sat, Dec 20, 2014 at 5:34 AM, Peter Rabbitson <rabbit+dbic at rabbit.us>
wrote:

> On 10/10/2014 06:37 AM, Bill Moseley wrote:
>
>> On Thu, Oct 9, 2014 at 6:32 PM, Ben Tilly <btilly at gmail.com
>> <mailto:btilly at gmail.com>> wrote:
>>
>>     The obvious thing to try is to use the alarm() function to send
>>     yourself a signal and set a signal handler that will just die to
>>     escape.  But this is unlikely to work due to safe signals.  Search for
>>     "Safe Signals" in perldoc perlipc for details.  It will also show you
>>     how to use the POSIX module to set a signal handler that can work
>>     despite that.
>>
>>
>> But where?   Set storage_type and override/wrap the private method
>> _connect or _populate_dbh?  I'm wondering what's a good place to hook
>> into.
>>
>>
> Hi Bill
>
> I am going through my backlog, wondering if you still need help with this
> or you figured out a way forward?



Hi Peter,

No, I never followed up and made any code changes.

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.

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.

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.


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.



-- 
Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20141221/e8aac37e/attachment.htm>