further investigation leads me to think this is true. i can make my
app sleep for 60 seconds and i don't get
it marked as down or show missed health checks in haproxy. the one
caveat is that if i delete the check.txt
from my public directory then i get missing file check.txt in my rails
production logs (whereas i don't see
anything in the production logs if check.txt is present). so i assume
then that, on not finding a static file,
mongrel passes it back to rails routing. so my solution is to replace
my empty check.txt with a check.txt
that contains a 404 header. that should keep my checks out of rails
logs and threads.

while this is an imperfect solution as it could be that mongrel is up
but rails is broken, but given the alternative
of having to do very infrequent checking to not interfere with normal
traffic, this seems preferable.

i would, of course, appreciate any feedback or comments.

thanks....gg

On Oct 4, 6:37 am, buddy12lbcat <[email protected]> wrote:
> hi,
>
> a question to the group:
>
> am i right in thinking that rails routing occurs outside (before) the
> mutex lock on dispatch such that static files get served up on a
> different thread than rails script requests. they both go through
> routes.rb though.
>
> if that is the case then i shouldn't have to worry about haproxy
> sending health checks to my mongrel blocking actual rails requests as
> long as the checks are requesting a static file (eg /ror/public/
> check.txt). is that accurate? similarly, if i have a long running
> request on rails, the mutex should have the one thread locked but
> allow requests for non-rails dispacted request (eg static files).
>
> thanks....gg
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Talk" 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/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to