From: Ezra Zygmuntowicz <ezmobius@...>
Date: 2010-03-09T08:52:46+09:00
Subject: Re: asynchronous network access with Rack?


On Mar 8, 2010, at 3:13 PM, Tom Reilly wrote:

> I've used threading with getting several web pages for a long time and I've never had any problem so long as you catch errors if a specifc web page can't be obtained.
> Tom Reilly
> 
> Nick Brown wrote:
>> I've read that "threading is considered harmful" for Ruby web apps.
>> Well, I'm writing a Sinatra app which will build a page based on the
>> responses of several servers (Net::HTTP.get). I want to do these .gets
>> in parallel, as doing them synchronously would obviously mean the users
>> would wait for a long time.
>> 
>> Would it be "considered harmful" to do:
>> 
>>   resp_a, resp_b, resp_c = nil
>>   thread_a = Thread.new { resp_a = Net::HTTP.get site_a }
>>   thread_b = Thread.new { resp_b = Net::HTTP.get site_b }
>>   thread_c = Thread.new { resp_c = Net::HTTP.get site_c }
>>   thread_a.join
>>   thread_b.join
>>   thread_c.join
>> 
>> Is there any possible harm that could come from this? Can threading
>> interfere with Rack in some way? I haven't done much previous
>> development of threaded apps, so I would appreciate any tips.


	IMHO you would be better served using the 'thin' rack comat web server and using its async mode along with EM::HTTP::Request. This way you could use event driven style to hve zero threads and basically pause the clients request connection while you make async calls to all the other web services, once they all return then you fire the async callback for thin to resume the clients connection and return the results.

	Doing it this way will require a bit more mental twisting to get all the async stuff correct but it will be far more scalable and will serve you much better in the end.

Cheers-

Ezra Zygmuntowicz
ez@engineyard.com