Thread.current persistence

[buddycat]

hi,

i use Thread.current to store stuff like User.current, Org.current and
some other "current" models so that they are available everywhere in a
given request. this works flawlessly (or at least seems to) on
mongrel, but when i upgraded to 2.3 and passenger, it seems that
Thread.current now persists the values across requests for the same
user, so what was true for a given page is still true for the next
page. not good. my expectation is that Thread.current gets wiped at
the end of every request.

my setup: using rails2.3, ruby1.9.1p0 on passenger1.3.1/apache2-mpm-
worker (threaded)

is this expected behavior from passenger? please confirm that
Thread.current is still "thread safe" and not now being stored in a
session var under the covers. or does is just mean that all requests
for a given app run on the same thread and that thread persists in
passenger. in a way it seems similar to db pooling where the
connection is persisted, but generally, most poolers sanitize the
connection between requests. i guess i was expecting same.

thanks for your hard work on passenger. seems better than mongrel
already.

[Maurício Linhares]

You should not expect to have the Thread.current variable to be
"cleaned up" as Rails or anything else could be using a thread pool to
serve requests.

After every request, clean up the variables you have set to the
Thread.current hash.

-
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) | http://blog.codevader.com/ (en)

[buddycat]

correction, make that passenger 2.1.3

[buddycat]

ok. that makes sense. guess mongrel just creates new thread for each
request so it never came up.

[buddycat]

fyi,

doing grep -irn thread.current vendor/rails reveals several places
where thread.current is used like so:

thread.current(blah) ||= somevalue

this would suggest that if passenger isn't sanitizing thread.current
and rails isn't either (not my app but rails core), then there are
values that are being persisted across requests that shouldn't be.
searching this group for thread.current shows one other person with
locale issues along these lines and rails indeed does use
thread.current in i18n.

[buddycat]

ror/vendor/rails/activesupport/lib/active_support/vendor/i18n-0.1.3/
lib/i18n.rb:40: Thread.current[:locale] ||= default_locale
ror/vendor/rails/activesupport/lib/active_support/core_ext/time/
zones.rb:15: Thread.current[:time_zone] || zone_default
ror/vendor/rails/activerecord/lib/active_record/base.rb:2189:
Thread.current[:"#{self}_scoped_methods"] ||= self.default_scoping.dup


some examples...

[Maurício Linhares]

Well, I never had any problems with this, specially locales, as I
always set them directly before every request.

But what i said still stands, clean up whatever you added there and
you should have no problems. The core rails team says that rails is
threadsafe, if you find a problem with that, file a bug at lighthouse.

-
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) | http://blog.codevader.com/ (en)

[buddycat]

ok. i guess i am just wondering if the rails core team's assumption is
that you serve up a new thread for each request. if so, then that
would seem to create conflicts. i will post something on lighthouse to
see what the rails guys have to say about whether they expect a new
thread each request.

thanks...gg


On Apr 7, 3:54 pm, Maurício Linhares <mauricio.linha...@gmail.com>
wrote:

> Well, I never had any problems with this, specially locales, as I
> always set them directly before every request.
>
> But what i said still stands, clean up whatever you added there and
> you should have no problems. The core rails team says that rails is
> threadsafe, if you find a problem with that, file a bug at lighthouse.
>
> -
> Maurício Linhareshttp://alinhavado.wordpress.com/(pt-br) |http://blog.codevader.com/(en)
>

[Hongli Lai]

On Tue, Apr 7, 2009 at 9:59 PM, buddycat <buddy1...@gmail.com> wrote:
>
> ok. i guess i am just wondering if the rails core team's assumption is
> that you serve up a new thread for each request. if so, then that
> would seem to create conflicts. i will post something on lighthouse to
> see what the rails guys have to say about whether they expect a new
> thread each request.

I'm pretty sure they don't. Any such assumption is a bug. After all
Thin doesn't use threads, and neither does the Rails FastCGI handler.
Mongrel is the only app server that spawns a thread for each request.

--
Phusion | The Computer Science Company

Web: http://www.phusion.nl/
E-mail: in...@phusion.nl
Chamber of commerce no: 08173483 (The Netherlands)

[buddycat]

hey thanks! that really clarifies things. i posted the above linees of
code from rails core to rails talk google group. no replies as yet. i
really appreciate your response and, of course, passenger.

On Apr 7, 6:28 pm, Hongli Lai <hon...@phusion.nl> wrote:

> On Tue, Apr 7, 2009 at 9:59 PM, buddycat <buddy12lb...@gmail.com> wrote:
>
> > ok. i guess i am just wondering if the rails core team's assumption is
> > that you serve up a new thread for each request. if so, then that
> > would seem to create conflicts. i will post something on lighthouse to
> > see what the rails guys have to say about whether they expect a new
> > thread each request.
>
> I'm pretty sure they don't. Any such assumption is a bug. After all
> Thin doesn't use threads, and neither does the Rails FastCGI handler.
> Mongrel is the only app server that spawns a thread for each request.
>
> --
> Phusion | The Computer Science Company
>
> Web:http://www.phusion.nl/

> E-mail: i...@phusion.nl