Bharanee Rathna <[email protected]> wrote: > On Wed, Jun 1, 2011 at 9:48 AM, Eric Wong <[email protected]> wrote: > > Bharanee Rathna <[email protected]> wrote: > >> I'm encountering a weird error where the unicorn workers are stuck in > >> a loop after hitting a 500 on the backend sinatra app. > > > > Also, what extensions are you using in your app? > > heaps of em. yajl, swift, rmagick, fastcaptcha, flock, nokogiri & > curb. except swift and curb none of the others would be touching the > network.
So are any of them hitting Unicorn from a Unicorn worker itself? This only happens when your app hits a 500? I would not write an app that does that, but if you do, be sure to shutdown any open connections on a 500 (or avoid the error in the first place) ... > >> strace at the point where it starts to go into a loop of death Actually, the sched_yield() only started when you hit sent SIGINT. > > What triggered SIGINT? > > not sure > > > > Actually, after many lines of sched_yield() in your gist, I can see it > > does actually exit the process. Did you kill it with SIGINT? If so, I > > see nothing wrong... > > yes i killed it after the worker looked stuck and wasn't responding for 30s So you hit Ctrl-C (which sends SIGINT)? So basically somebody from 10.1.1.4 opened a connection on Unicorn and just let it sit idle there. That somebody at 10.1.1.4 could've been the worker that triggered the 500 (and forgot it had open ccnnections) or a third party that made a request but sit idle because it couldn't handle the 500 which your Unicorn worker sent. From what I understand so far, it's not a Unicorn problem, but something in your app. Also, you wouldn't have this problem if nginx is in front of Unicorn since nginx won't open a connection and sit idle before making a request. -- Eric Wong _______________________________________________ Unicorn mailing list - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
