[Nitro] FastCGI is broken because of Og.thread_safe not having an Og.manager.store

Bryan Soto bryan.a.soto at gmail.com
Thu Jan 26 20:38:05 EST 2006

On 1/26/06, Rob Pitt <rob at motionpath.com> wrote:
> Og.manager.store returned nil causing lots of Og functions to stop
> working. Using irb from a separate thread in the same process revealed
> @store_class and @options were setup OK (and store really was nil).
> I could get a backtrace later, where do you want a backtrace from, from
> the part of the code that generates the connection pool?
I was just trying to understand what the problem was. I guess a backtrace
wouldn't be useful if it's just no method errors.

It looks like you could be getting nil as store if you're running a
multi-threaded app running more than five threads. Specifically, the line in

st = @pool.pop()

Array#pop, which Pool subclasses, returns nil from an empty array.

If that's the case, it looks like you should set :connection_count
(og/lib/og/manager.rb:66) in the Og.setup hash to something higher than 5 or
add calls to Og::Manager#put_store from the thread when you're done with it.

If that's not the case, then maybe you're running into errors connecting to
your database? If you're not running a multi-threaded app, could you try
disabling the auto-reload of files? That runs in a separate thread, and if
you're reloading the file containing Og#setup, that might be what's taking
all your pooled connections.

George, should Og.thread_safe really default to true? Please note that in
Manager#get_store, Thread.current is retrieved and a thread local variable,
og_store, is set. In a single-threaded app, this would have the affect of
only allowing a single connection for the entire app which is the problem
Lars was running into in


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060126/92a0e669/attachment.html 

More information about the Nitro-general mailing list