current status of threaded mode?

[John Bachir]

A year and a half ago Marc-Andre said he would never use threaded mode in production: https://groups.google.com/forum/#!searchin/thin-ruby/thread/thin-ruby/-POjw7T99pU/LL4q4bPp9XMJ

Is that still the case?

I've successfully got it serving asynchronous requests. See example app here: https://github.com/jjb/threaded-rails-example

Cheers,

John

[macournoyer]

I've never used it in production. Threaded mode is relying on EventMachine thread pool, which has been around for quite some time.

That being said, you don't need threads to build an asynchronous/real-time Rails app. Eg.: you can use https://github.com/jcoglan/faye as a middleware w/o thread.

[John Joseph Bachir]

On Wed, Nov 16, 2011 at 10:04 AM, macournoyer <macou...@gmail.com> wrote:

That being said, you don't need threads to build an asynchronous/real-time Rails app. Eg.: you can use https://github.com/jcoglan/faye as a middleware w/o thread.

Interesting. Do you mean that one can use a pub-sub architecture to design an asynchronous system, or that I can actually install some component of faye as a Rack middleware and deploy the code example I linked above in an asynchronous fashion?

[John Joseph Bachir]

Ah-- I just figured out that you meant: Faye is asynchronous with no special deployment needs. Got it :)

[James Coglan]

On Wednesday, November 16, 2011 3:59:27 PM UTC, John Bachir wrote:

Interesting. Do you mean that one can use a pub-sub architecture to design an asynchronous system, or that I can actually install some component of faye as a Rack middleware and deploy the code example I linked above in an asynchronous fashion?

You don't need Faye in order to make async responses, you just need to use env['async.callback'] and use a Deferrable as the body. Look at Faye's RackAdapter class to see how it interfaces with Thin -- you can use that same pattern in any Thin app. 

[Marc-André Cournoyer]

Indeed you don't need faye to achieve that.

Although your example would not work w/ Thin async callback because you are using sleep. Which is blocking the event loop. If what you really want to do is keep a connection opened will processing other requests, then the async callback will work.

Hope this is clear.

--
You received this message because you are subscribed to the Google Groups "thin-ruby" group.

To view this discussion on the web visit https://groups.google.com/d/msg/thin-ruby/-/pnMu86hJ84cJ.

To post to this group, send email to thin...@googlegroups.com.
To unsubscribe from this group, send email to thin-ruby+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/thin-ruby?hl=en.

--

M-A

http://macournoyer.com

[John Joseph Bachir]

On Nov 16, 2011, at 2:23 PM, Marc-André Cournoyer <macou...@gmail.com> wrote:

> Although your example would not work w/ Thin async callback because you are using sleep. Which is blocking the event loop. If what you really want to do is keep a connection opened will processing other requests, then the async callback will work

Does using the asynchronous callback model require a certain style of app development, or only the middleware stack?

my only goal is to allow one request which is waiting on IO (like a call to the DB or a remote service) to not block other requests. my understanding is that the only thing I need to do is make sure my app is threadsafe, and run thin in threaded mode. oddly I've seen essentially zero discussion about this type of deployment so I'm worried I'm missing something. maybe it's because all the folks doing threads also want parallel IO so they are using JRuby.

[Marc-André Cournoyer]

Does using the asynchronous callback model require a certain style of app development, or only the middleware stack?

No, but you have to be careful not to do any long blocking call (like your sleep for eg.). In my eg. w/ Faye, only the middleware is required to be asynchronous, but the Rails app not, although it should response fairly quickly.

 

my only goal is to allow one request which is waiting on IO (like a call to the DB or a remote service) to not block other requests. my understanding is that the only thing I need to do is make sure my app is threadsafe, and run thin in threaded mode. oddly I've seen essentially zero discussion about this type of deployment so I'm worried I'm missing something. maybe it's because all the folks doing threads also want parallel IO so they are using JRuby.

If you're only blocking operation is IO, it's better not rely on threads and use async IO. See https://github.com/igrigorik/async-rails.

--

M-A

http://macournoyer.com

[James Tucker]

It's worth remembering that as long as you're using well written libraries (i.e. mysql2 instead of mysql, and so on), then rb_thread_select and MRIs green threads /are/ a basic fibered reactor pattern, whilst still providing an easy synchronous approach to development.

In essence, what I'm saying is, using net/http or mysql2 with thin in threaded mode can work great.

On non-MBARI patched versions of 1.8.x then you may want to wrap the thin binary like so:

require 'rubygems'

require 'eventmachine'

EM.next_tick { EM.defer {} }

gem 'thin'

EM.run do

load Gem.bin_path('thin', 'thin')

end

The above code will make a binary that feels just like thin(1), but will run 30+% faster on non-MBARI MRI rubies.

--

M-A

http://macournoyer.com

--
You received this message because you are subscribed to the Google Groups "thin-ruby" group.

[John Joseph Bachir]

On Thu, Nov 17, 2011 at 1:33 PM, James Tucker <jftu...@gmail.com> wrote:

It's worth remembering that as long as you're using well written libraries (i.e. mysql2 instead of mysql, and so on), then rb_thread_select and MRIs green threads /are/ a basic fibered reactor pattern, whilst still providing an easy synchronous approach to development.

In essence, what I'm saying is, using net/http or mysql2 with thin in threaded mode can work great.

Great to hear. Have you done this in production? Would be great to hear more about your experiences.