Thread.new with ActiveRecord under Mongrel vs. FastCGI

Hi All,

I’m going to end up hosting a site on a server in a fastcgi environment,
but I’ve been doing most of my development under mongrel. I have a bit
of code that spawns a thread, and in the thread it makes some remote
calls (openuri) and does some database inserts via activerecord.

When I do this under FastCGI, everything appears to work as expected.
When I do it under Mongrel, things almost work but I consistently get
an error when saving records to the database.

I have a class Bookmark, that has a belongs_to relationship with User,
and when I assign the user to the bookmark:

azbm.user = auser

I get the error:

User expected, got User
/usr/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/associations/association_proxy.rb:134

and then more of a stack trace. Obviously the message is weird (the
class it reports and the class it got are the same). I also know the
code works fine in Mongrel if I’m not using threads, and it works fine
in FastCGI with or without threads.

Any ideas what’s going on? As a workaround, is there any way for me to
tell programmatically whether I’m in Mongrel or FastCGI, so that I can
have the code work during development (albeit slower) and production
(with the use of threads).

Thanks!
Tom

On Mon, 2006-07-24 at 03:12 +0200, Tom L. wrote:

/usr/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/associations/association_proxy.rb:134

Typically these errors come from firing off a thread that tries to use
the User model before the dispatcher has actually loaded it. Dispatcher
does not like threads (or used to hate them).

In any case, first thing you have to do when AR complains that a class
don’t exist is:

  1. clear all your sessions.
  2. at the top of the action explicitly set the model :user.
  3. at the top of the action .rb file require the user.rb model file.

Try them in order and see if any work.


Zed A. Shaw

http://mongrel.rubyforge.org/
http://www.railsmachine.com/ – Need Mongrel support?

Zed S. wrote:

On Mon, 2006-07-24 at 03:12 +0200, Tom L. wrote:

/usr/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/associations/association_proxy.rb:134

Typically these errors come from firing off a thread that tries to use
the User model before the dispatcher has actually loaded it. Dispatcher
does not like threads (or used to hate them).

In any case, first thing you have to do when AR complains that a class
don’t exist is:

  1. clear all your sessions.
  2. at the top of the action explicitly set the model :user.
  3. at the top of the action .rb file require the user.rb model file.

Try them in order and see if any work.

None of them worked, unfortunately.

If it’s worth anything, the code I’m executing in a thread, as well as
the location where the thread itself is spawned, is in a helper, not the
controller directly. If it’s useful, here is the full stack trace:

User expected, got User
/usr/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/associations/association_proxy.rb:134:in
raise_on_type_mismatch' /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/associations/belongs_to_association.rb:22:inreplace’
/usr/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/associations.rb:850:in
user=' /home/tlianza/workspace/wishlisting/config/../app/helpers/giftalicious_helper.rb:178:inprivate_get_wishlist_from_amazon’
/home/tlianza/workspace/wishlisting/config/…/app/helpers/giftalicious_helper.rb:167:in
private_get_wishlist_from_amazon' /home/tlianza/workspace/wishlisting/config/../app/helpers/giftalicious_helper.rb:141:inupdate_amazon_wishlist’
/home/tlianza/workspace/wishlisting/config/…/app/helpers/giftalicious_helper.rb:140:in
update_amazon_wishlist' /home/tlianza/workspace/wishlisting/config/../app/controllers/giftalicious_controller.rb:299:inlogin’
/usr/lib/ruby/gems/1.8/gems/actionpack-1.12.3/lib/action_controller/base.rb:910:in
perform_action_without_filters' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.3/lib/action_controller/filters.rb:368:inperform_action_without_benchmark’
/usr/lib/ruby/gems/1.8/gems/actionpack-1.12.3/lib/action_controller/benchmarking.rb:69:in
perform_action_without_rescue' /usr/lib/ruby/1.8/benchmark.rb:300:inmeasure’
/usr/lib/ruby/gems/1.8/gems/actionpack-1.12.3/lib/action_controller/benchmarking.rb:69:in
perform_action_without_rescue' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.3/lib/action_controller/rescue.rb:82:inperform_action’
/usr/lib/ruby/gems/1.8/gems/actionpack-1.12.3/lib/action_controller/base.rb:381:in
process_without_filters' /usr/lib/ruby/gems/1.8/gems/actionpack-1.12.3/lib/action_controller/filters.rb:377:inprocess_without_session_management_support’\n/usr/lib/ruby/gems/1.8/gems/actionpack-1.12.3/lib/action_controller/session_management.rb:117:in
process' /usr/lib/ruby/gems/1.8/gems/rails-1.1.4/lib/dispatcher.rb:38:indispatch’
/usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel/rails.rb:73:in
process' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:551:inprocess_client’
/usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:550:in
process_client' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:636:inrun’
/usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:636:in run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:625:inrun’
/usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:956:in run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel.rb:955:inrun’
/usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/bin/mongrel_rails:127:in
run' /usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/lib/mongrel/command.rb:199:inrun’
/usr/lib/ruby/gems/1.8/gems/mongrel-0.3.13.3/bin/mongrel_rails:235
/usr/bin/mongrel_rails:18

Thanks again,
Tom