Prematurely closed connection

Prematurely closed connection

[Paul Carey]

Hi

I've come across a puzzling issue. The code segment below works as
expected, but if I replace :error => true with :error =>
invite.errors, nginx serves a 502 as per the log below. invite.errors
is normal hash.

I'm using a bundled merb 1.1 with Unicorn 0.99. Unicorn is a system
gem. I'm running nginx 0.7.65. I've only experienced this issue with
nginx / unicorn.
I'd be grateful for any thoughts or pointers.

Many thanks
Paul

== controller action, serving json
if invite.save
  display :ok => true
else
  Merb.logger.info "invite.errors #{invite.errors}"
  display :error => true
end

== nginx.log
2010/05/13 16:34:03 [error] 11448#0: *226 upstream prematurely closed
connection while reading response header from upstream, client:
78.147.1.152, server: _, request: "PUT
/invites/726a50c3400d2fa16c7ec9e29512ac2cb69b52c8 HTTP/1.1", upstream:
"http://unix:/var/apps/sd/tmp/unicorn.sock:/invites/726a50c3400d2fa16c7ec9e29512ac2cb69b52c8",
host: "ec2-174-129-71-76.compute-1.amazonaws.com", referrer:
"http://ec2-174-129-71-76.compute-1.amazonaws.com/events/djk5qipe87bas51z0qrgeukrr"

== unicorn.stderr.log
I, [2010-05-13T16:34:03.869423 #15332]  INFO -- : reaped
#<Process::Status: pid 15398 SIGSEGV (signal 11)> worker=15I,
[2010-05-13T16:34:03.890454 #15429]  INFO -- : worker=15 spawned
pid=15429
I, [2010-05-13T16:34:03.890669 #15429]  INFO -- : worker=15 readyI,
[2010-05-13T16:34:55.650233 #15332]  INFO -- : reloading
config_file=config/unicorn.rb
I, [2010-05-13T16:34:58.583076 #15332]  INFO -- : Refreshing Gem list
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Prematurely closed connection

[Eric Wong]

Paul Carey <paul.p.carey@gmail.com> wrote:
> Hi
> 
> I've come across a puzzling issue. The code segment below works as
> expected, but if I replace :error => true with :error =>
> invite.errors, nginx serves a 502 as per the log below. invite.errors
> is normal hash.
> 
> I'm using a bundled merb 1.1 with Unicorn 0.99. Unicorn is a system
> gem. I'm running nginx 0.7.65. I've only experienced this issue with
> nginx / unicorn.
> I'd be grateful for any thoughts or pointers.
> 
> Many thanks
> Paul
> 
> == controller action, serving json
> if invite.save
>   display :ok => true
> else
>   Merb.logger.info "invite.errors #{invite.errors}"
>   display :error => true
> end

<snip>

Hi Paul,

> == unicorn.stderr.log
> I, [2010-05-13T16:34:03.869423 #15332]  INFO -- : reaped
> #<Process::Status: pid 15398 SIGSEGV (signal 11)> worker=15I,
                               ^^^^^^^

Uh oh, something is causing the Unicorn process to segfault in the
response phase.  Since Unicorn is only running Ruby code at that point,
I suspect there's something in your JSON enoder that's not liking
the serialization of invite.errors...

I'm not familiar with Merb at all, but I'd be curious to see how your
JSON encoder is handling the "invite.errors" hash.

Which version of Ruby, JSON/Yajl library, etc are you using?

Can you get us a backtrace?

Can you run with RACK_ENV=development to get Rack::Lint onto your
middleware stack?  Perhaps Merb isn't returning a 100% valid Rack
response and Rack::Lint will notice.

Thanks for any info you can provide.

-- 
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Prematurely closed connection

[Paul Carey]

>> == unicorn.stderr.log
>> I, [2010-05-13T16:34:03.869423 #15332]  INFO -- : reaped
>> #<Process::Status: pid 15398 SIGSEGV (signal 11)> worker=15I,
>                               ^^^^^^^
>
> Uh oh, something is causing the Unicorn process to segfault in the
> response phase.  Since Unicorn is only running Ruby code at that point,
> I suspect there's something in your JSON enoder that's not liking
> the serialization of invite.errors...

Hi Eric

You're absolutely right. The problem had nothing to do with Unicorn.
JSON 1.4.3 was segfaulting on that particular hash - I don't know why
just yet - but all worked as expected when I reverted to JSON 1.4.2.

Many thanks

Paul
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying