The problem with all these approaches is that _some pages will break_. Neither the periodic check nor the check with counter approach are great because if the connection is lost it will not be re-established for n seconds / n requests. The best approach I found which avoids the per request overhead was to rescue the error and reconnect. Unfortunately the gone away error is just a generic mysql error so you'll be catching other errors too. I even tried to redirect to the requested page after rescuing and reconnecting but, while that sometimes works, sometimes you'll get infinite redirects which you'll never hear about - not great...
In the end it was decided that even rescuing caused too many breakages and we have had to settle for a per request check. (In my case I needed to connect to a remote database for some models which I'm sure increased the frequency of mysql "going away". So the tradeoff for others may be different.) Martyn On Tue, Oct 28, 2008 at 6:11 PM, Ezra Zygmuntowicz <[EMAIL PROTECTED]> wrote: > > > I would say maybe a tradeoff is in order? Maybe keep a counter of > requests and verify_active_connections every 10-50 requests? This way > you would not incur the overhead on every hit but would be likely to > keep the connection going? > > Or maybe we can add a global rescue for AR projects that catch the > connection errors and then call verify_active_connections? > > I don't use AR so I guess it is up to the folks who do to decide what > way is best> it is a tradeoff between always reconnecting and always > paying the price of connecting overhead. > > Cheers- > -Ezra > > > On Oct 28, 2008, at 10:32 AM, Michael Klishin wrote: > >> >> 2008/10/28 Steve Tooke <[EMAIL PROTECTED]>: >>> The problem also seems to occur if the MySQL server is restarted. >>> ActiveRecord holds on to the connection, and unless you check its >>> still valid it tries to use it, without retrying. So increasing the >>> wait_timeout variable or pinging MySQL every once in a while wouldn't >>> help with this. >> >> I am by no means a deployment expert but usually DB restart is >> something that is quite special, >> and servers cluster restart is not (god or monit do if for you as soon >> as the app hits memory limit, and a few people are worried about it). >> So doing a cluster restart is acceptable for simple applications that >> only use >> one DB and need no really high availability. This helps with >> disconnection issue. >> >> Adding an overhead to literally every request is something I'd rather >> avoid in the framework. If it's the way you choose, >> you can make a plugin out of this patch since it uses public Merb API >> (just one hook), so you can keep it around and add it to several >> applications. >> >> I'd rather go with a thread that wakes up every 5 minutes or so to >> ping MySQL server. >> -- >> MK >> >> > > > Ezra Zygmuntowicz > [EMAIL PROTECTED] > > > > > > > -- Martyn Loughran Creating fresh, flexible and fast-growing web applications is our passion. http://www.new-bamboo.co.uk --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/merb?hl=en -~----------~----~----~----~------~----~------~--~---
