Mongrel users - Nov 2007 - MySQL timeout value (was: mongrel - monit issue)

At 03:24 PM 11/7/2007, mongrel-users-request at rubyforge.org
wrote:
> > Thanks for this Kirk.  Yep, I was using 14400.  I''m switching
this
> to
> > 2 weeks: 1209600 and we''ll see if any further restarts are
needed
> by
> > monit.
>
>I''ve always wondered why 14400 is the number that is always passed
>around when talking about extending the timeout period.  Maybe there
>is some db issue with a _really_ long timeout like 1209600?
This has been discussed a few times on list I think. I believe the 
issue here is that you need the client end of the connection to timeout 
AFTER the server end of the connection. Setting this to arbitrarily 
large numbers will not do anything (afaik) b/c the server will time you 
out well before then anyway, and force the client to re-initialize of 
the pipe.

I think the goal here is to have the client time out *just* after the 
server times outs - you never want the client thinking the server is 
live when it''s not (that''s what causes the weird
"mongrel/rails seems
hung" problem), but it''s better to have both agree on the status
of the
pipe.

Steve

At 03:24 PM 11/7/2007, mongrel-users-request at rubyforge.org
wrote:
> > Thanks for this Kirk.  Yep, I was using 14400.  I''m switching
this
> to
> > 2 weeks: 1209600 and we''ll see if any further restarts are
needed
> by
> > monit.
>
>I''ve always wondered why 14400 is the number that is always passed
>around when talking about extending the timeout period.  Maybe there
>is some db issue with a _really_ long timeout like 1209600?
This has been discussed a few times on list I think. I believe the 
issue here is that you need the client end of the connection to timeout 
AFTER the server end of the connection. Setting this to arbitrarily 
large numbers will not do anything (afaik) b/c the server will time you 
out well before then anyway, and force the client to re-initialize of 
the pipe.

I think the goal here is to have the client time out *just* after the 
server times outs - you never want the client thinking the server is 
live when it''s not (that''s what causes the weird
"mongrel/rails seems
hung" problem), but it''s better to have both agree on the status
of the
pipe.

Steve

Steve,

It sounds like you''re referring to another setting on the MySQL  
side.  If the Rails timeout is just a little bit longer, then it will  
automatically reconnect.

Is this right?

Thanks,
Pete

On Nov 7, 2007, at 3:56 PM, Steve Midgley wrote:
> At 03:24 PM 11/7/2007, mongrel-users-request at rubyforge.org wrote:
>>> Thanks for this Kirk.  Yep, I was using 14400.  I''m
switching this
>> to
>>> 2 weeks: 1209600 and we''ll see if any further restarts are
needed
>> by
>>> monit.
>>
>> I''ve always wondered why 14400 is the number that is always
passed
>> around when talking about extending the timeout period.  Maybe there
>> is some db issue with a _really_ long timeout like 1209600?
>
> This has been discussed a few times on list I think. I believe the
> issue here is that you need the client end of the connection to  
> timeout
> AFTER the server end of the connection. Setting this to arbitrarily
> large numbers will not do anything (afaik) b/c the server will time  
> you
> out well before then anyway, and force the client to re-initialize of
> the pipe.
>
> I think the goal here is to have the client time out *just* after the
> server times outs - you never want the client thinking the server is
> live when it''s not (that''s what causes the weird
"mongrel/rails seems
> hung" problem), but it''s better to have both agree on the
status of
> the
> pipe.
>
> Steve
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

The way that I have put this issue to bed for people is with this  
crunchy little hack in their environment.rb:

Thread.new { loop { sleep 60*60  
ActiveRecord::Base.verify_active_connections! } }.priority = -10

	That little baby will keep your database connected.

Cheers-
-Ezra


On Nov 7, 2007, at 4:22 PM, Pete DeLaurentis wrote:
> Steve,
>
> It sounds like you''re referring to another setting on the MySQL
> side.  If the Rails timeout is just a little bit longer, then it will
> automatically reconnect.
>
> Is this right?
>
> Thanks,
> Pete
>
> On Nov 7, 2007, at 3:56 PM, Steve Midgley wrote:
>
>> At 03:24 PM 11/7/2007, mongrel-users-request at rubyforge.org wrote:
>>>> Thanks for this Kirk.  Yep, I was using 14400.  I''m
switching this
>>> to
>>>> 2 weeks: 1209600 and we''ll see if any further restarts
are needed
>>> by
>>>> monit.
>>>
>>> I''ve always wondered why 14400 is the number that is
always passed
>>> around when talking about extending the timeout period.  Maybe
there
>>> is some db issue with a _really_ long timeout like 1209600?
>>
>> This has been discussed a few times on list I think. I believe the
>> issue here is that you need the client end of the connection to
>> timeout
>> AFTER the server end of the connection. Setting this to arbitrarily
>> large numbers will not do anything (afaik) b/c the server will time
>> you
>> out well before then anyway, and force the client to re-initialize of
>> the pipe.
>>
>> I think the goal here is to have the client time out *just* after the
>> server times outs - you never want the client thinking the server is
>> live when it''s not (that''s what causes the weird
"mongrel/rails seems
>> hung" problem), but it''s better to have both agree on the
status of
>> the
>> pipe.
>>
>> Steve
>>
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

On Nov 7, 2007 9:33 PM, Ezra Zygmuntowicz <ezmobius at gmail.com>
wrote:
>
>
>         The way that I have put this issue to bed for people is with this
> crunchy little hack in their environment.rb:
>
> Thread.new { loop { sleep 60*60
> ActiveRecord::Base.verify_active_connections! } }.priority = -10
>
>         That little baby will keep your database connected.
>
Hey Ezra, this 60*60 big sleep wouldn''t hurt threading? so far big
sleepy threads didn''t work as expected for me.

That could be another cross-platform misbehaving, but just asking :-)

Regards,

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi