Hi Everyone,
I'm running a Rails site on Mongrel and I can't figure out why a
particular type of request ties up Mongrel easily. The requests that
tie up Mongrel call an XML-RPC server like so:
# In the controller
def site_start
if params[:id]
@site = Site.find(params[:id])
Do the RpcTask task methods end up using ruby threads to do their
work? That call_async method definitely sounds suspiciously like it
might.
I've found that ruby threads under mongrel (although I don't think it's
neccesarily an issue specific to mongrel) sometimes block when you don't
Hi Jonathan,
I thought that maybe using 'call_async' rather than simply 'call'
might improve the situation but the behavior is the same with either
call.
Thomas Allen
On Wed, Nov 18, 2009 at 12:53 PM, Jonathan Rochkind rochk...@jhu.edu wrote:
Do the RpcTask task methods end up using ruby
Thanks for suggesting that the problem may be related to threading. At
least on this Debian box, changing RpcTask.run to the following seems
to do the trick:
def run(task, task_params = {})
Thread.new {
server = XMLRPC::Client.new2('http://localhost:9192/')
server.call(task,task_params)
Cool, glad you solved it. Threading in ruby has all sorts of gotchas.
Although I can't possibly explain why your new way works, it seems odd
to me, although it does seem to confirm that _something_ about threading
is what was causing you problems. Out of curiosity, what was
RpcTask.run
I didn't want to shoot off another email so soon, but it turns out
that code did not fix the problem. It seemed to because I was running
the mongrel on another port and this revealed the real problem: The
task being invoked on the other side logs certain information both to
a file and via HTTP
Then again, this test (against a single mongrel started with the
production env) demonstrates that the site can handle a great number
of these logging requests:
% siege
http://localhost:9191/sites/log?site_id=1msg=Memcached%3A+Startinglevelname=INFO;
** SIEGE 2.68
** Preparing 10 concurrent
