[Nitro] FastCGI is broken because of Og.thread_safe not having an Og.manager.store
george.moschovitis at gmail.com
Thu Jan 26 04:27:03 EST 2006
I fixed some newly introduced Og/FCGI problems some days ago. Do you
still see the problem
in the latest glycerin version?
On 1/26/06, Bryan Soto <bryan.a.soto at gmail.com> wrote:
> On 1/25/06, Rob Pitt <rob at motionpath.com> wrote:
> > Recently (I am not sure when) our programs were broken by a Glycerin
> > patch (unfortunately I haven't been able to work out which) that caused
> > Og.thread_safe to be true and for Og.manager.store to not exist.
> It seems Og.thread_safe = true is the default now in og/lib/og.rb. Perusing
> bundles since late December doesn't show this changed. Nor anything really
> having to do with Og itself actually. And Og.manager.store looks as though
> it should work, even with a Pool. I don't suppose you have a backtrace or
> maybe could describe how things broke?
> > I notice there is some code in the adapters/fastcgi.rb that is supposed
> > to turn this off but it never appears to run even though
> > ENV["NITRO_INVOKE"]=>"fcgi_proc".
> I don't think this would do anything since it's called through Nitro.run
> after the pertinent code in Manager#initialize is run.
> > The quick fix is to to put this line directly before Nitro.run in your
> > projects:
> > Og.thread_safe = false
> I'm actually surprised that works. Looking at og/manager.rb initialize, it
> checks for the value of Og.thread_safe when creating the manager, typically
> when Og.setup is called. Or perhaps you don't structure your run.rb file the
> conventional way?
> > But that's hardly ideal. I spent most of the time I should have spent
> > fixing this working out how to get an in-process irb shell within
> > running fast-cgi processes so perhaps someone else can look at this (and
> > find this helpful if they start experiencing this odd problem too).
> I ran into some odd threading issues while working on the test suite, but
> can't remember exactly what I did to cause them. The only line from the
> backtrace I remeber now was a call to synchronize, which is how I knew it
> was a threading issue. Is that what you're experiencing?
> Nitro-general mailing list
> Nitro-general at rubyforge.org
More information about the Nitro-general