# In memory subrequest hang if backend return 500

**URL:** <https://www.ruby-forum.com/t/in-memory-subrequest-hang-if-backend-return-500/218095>\
**Category:** NGINX\
**Created:** [March 21, 2012, 3:54am UTC](https://www.ruby-forum.com/t/in-memory-subrequest-hang-if-backend-return-500/218095 "2012-03-21T03:54:12Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\
**Post date:** [March 21, 2012, 3:54am UTC](https://www.ruby-forum.com/t/in-memory-subrequest-hang-if-backend-return-500/218095/1 "2012-03-21T03:54:12Z")

</div>

Hi All,

In the file ngx\_http\_upstream.c I found some code like this:

1618 if (u-\>headers\_in.status\_n \> NGX\_HTTP\_SPECIAL\_RESPONSE) {  
1619  
1620 if (r-\>subrequest\_in\_memory) {  
1621 u-\>buffer.last = u-\>buffer.pos;  
1622 }

that means, if the status backend return if greater than 300, the first  
part of the body would be abandoned. Will this cause the issue that the  
main request won’t be woken again and keep sleeping until timeout? Or  
did I  
misunderstand anything?

Yours,  
Abioy

---

<div class="post-metadata">

**Author:** ![Abioy\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/71e660/32.png) [@Abioy\_S](https://www.ruby-forum.com/u/Abioy_S)\
**Post date:** [March 21, 2012, 9:54am UTC](https://www.ruby-forum.com/t/in-memory-subrequest-hang-if-backend-return-500/218095/2 "2012-03-21T09:54:39Z")

</div>

Hello!

On Wed, Mar 21, 2012 at 10:53:45AM +0800, Abioy S. wrote:

> that means, if the status backend return if greater than 300, the first  
> part of the body would be abandoned. Will this cause the issue that the  
> main request won’t be woken again and keep sleeping until timeout? Or did I  
> misunderstand anything?

Do you use keepalive connections to backends?

As far as I see, this may indeed cause problems with keepalive  
connections, though should be ok in non-keepalive case.

Maxim D.
