# Some Ajax requests hang

**URL:** <https://www.ruby-forum.com/t/some-ajax-requests-hang/183624>\
**Category:** Mongrel\
**Created:** [February 17, 2010, 4:04pm UTC](https://www.ruby-forum.com/t/some-ajax-requests-hang/183624 "2010-02-17T16:04:32Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![tomuhs](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/ecb155/32.png) [@tomuhs](https://www.ruby-forum.com/u/tomuhs)\
**Post date:** [February 17, 2010, 4:04pm UTC](https://www.ruby-forum.com/t/some-ajax-requests-hang/183624/1 "2010-02-17T16:04:32Z")

</div>

I have a Rails 2.2.2 site that is running on four mongrels, balanced  
via Apache and mod\_balancer. This architecture has worked very  
efficiently in the past, but I’m now observing requests hanging almost  
indefinitely with a newer version of the site. I haven’t yet been able  
to pin this on anything in particular, as the nature of the requests  
is fairly similar between the two site versions.

More importantly, I don’t know how to investigate the trouble further,  
which is why I’m writing to this list.

On a given site, a particular request seems to be able to completely  
tie up a Mongrel. It doesn’t take long before all four are tied up,  
rendering the site essentially unusable. Here is an example of an  
action which I’ve confirmed does this. “extjs” is a convenience  
function that with the provided args below simple does a render :json.  
This action is requested with the POST method and a single param:

class DocumentController  
def family  
if params[:id]  
doc = Document.find(params[:id])  
if doc  
extjs :family =\> doc.family  
else  
extjs :success =\> false  
end  
else  
extjs :success =\> false  
end  
end  
end

class Document  
def family  
Document.all(:conditions =\> { :parent\_id =\> self.parent\_id })  
end  
end

The model method returns at most fewer than ten documents, and for the  
majority documents only the document itself, so I don’t see anything  
that would tie up the server. The document lookup itself is very  
efficient and is used elsewhere with no problems. Is there anything  
about this action that suggests it would cause the behavior I’ve  
observed?

Thanks,  
Thomas A.