memcache/interlock problem (i think?)

Hey all

I have a line of code that's causing a "undefined method `include?' for
nil:NilClass" exception, but i can't work out what's actually going
wrong with it. After a bit of experimentation i discovered that it's
caused by simply asking for the id of an AR object i have.

          ldb " = #{}"

ldb is just a logging method i have - it's not the problem as i got the
same error initially when i tried to use in a find call.
Here's the line with some other logging output and the stack trace:

          ldb "options = #{options.inspect}"
          ldb "question = #{question.inspect}"
          ldb " = #{}"

stack trace and debug logger output:

### ./app/models/quiz.rb:458:in `auto_generate_quizzes_from_questions':
options = {:age_group_id=>3, :style=>"sequential", :tag=>#<Tag id: 60,
name: "speaking", created_at: nil>, :size=>6}
### ./app/models/quiz.rb:459:in `auto_generate_quizzes_from_questions':
question = #<Question id: 619, text: "Which of these words has only one
syllable?", kind: "text", media_instruction_text: nil, qid: "619",
editor_id: 22, editor_name: "Ian McNeilly", user_id: 15, author_ext_id:
"22", original_target_age: "11", qtype: "Curriculum", keywords: "--- \n-
Curriculum\n- English\n- School\n- Which\n- has\n...", created_at:
"2010-02-25 13:20:02", updated_at: "2010-04-01 16:17:03", checked:
false, subject_id: 1, official: nil, privacy: 1>

NoMethodError (undefined method `include?' for nil:NilClass):
  lib/core_extensions.rb:6:in `method_missing'
  app/models/quiz.rb:460:in `auto_generate_quizzes_from_questions'
  app/models/quiz.rb:456:in `each'
  app/models/quiz.rb:456:in `auto_generate_quizzes_from_questions'
  app/controllers/admin/subjects_controller.rb:9:in `make_quizzes'
  vendor/plugins/haml/rails/./lib/sass/plugin/rack.rb:44:in `call'
  /usr/lib/ruby/1.8/mongrel/rails.rb:76:in `process'
  /usr/lib/ruby/1.8/mongrel/rails.rb:74:in `synchronize'
  /usr/lib/ruby/1.8/mongrel/rails.rb:74:in `process'
  /usr/lib/ruby/1.8/mongrel.rb:159:in `process_client'
  /usr/lib/ruby/1.8/mongrel.rb:158:in `each'
  /usr/lib/ruby/1.8/mongrel.rb:158:in `process_client'
  /usr/lib/ruby/1.8/mongrel.rb:285:in `run'
  /usr/lib/ruby/1.8/mongrel.rb:285:in `initialize'
  /usr/lib/ruby/1.8/mongrel.rb:285:in `new'
  /usr/lib/ruby/1.8/mongrel.rb:285:in `run'
  /usr/lib/ruby/1.8/mongrel.rb:268:in `initialize'
  /usr/lib/ruby/1.8/mongrel.rb:268:in `new'
  /usr/lib/ruby/1.8/mongrel.rb:268:in `run'
  /usr/lib/ruby/1.8/mongrel/configurator.rb:282:in `run'
  /usr/lib/ruby/1.8/mongrel/configurator.rb:281:in `each'
  /usr/lib/ruby/1.8/mongrel/configurator.rb:281:in `run'
  /usr/lib/ruby/1.8/mongrel/command.rb:212:in `run'

Line 460 is the last one listed above. I can see from the debug output
that question is a regular AR object.

The reason that i thought it might be memcache/interlock related is that
if i restart mongrel then it magically works. Then the second time i
try it it breaks again. This is totally consistent, it always works
first time after restart and fails every subsequent time.

kind of stumped - any ideas anyone?

thanks, max

does it only happen if config.cache_classes is set to false (remember
to restart the app after you change that) ?


Hi Fred - good question - yes, it does. IE, setting cache_classes to
true fixes it. hmmm.

Though obviously i still want to fix it properly :slight_smile:

Hi Fred - good question - yes, it does. IE, setting cache_classes to
true fixes it. hmmm.

Posted via

You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Then it's a class reloading problem. When an activerecord class gets
reloaded, the old copy has all of its methods removed. If something is
still holding onto an instance like that and tries to call any methods
of it then it will fail


Frederick Cheung wrote:

ok - someone pointed me at this discussion

and i tried this patch

which seems to have worked. But there might be memory leaks as a
consequence, though in dev mode only. I'm a bit none the wiser for a
lot of that discussion's overall conclusions (if there were any, it
seemed quite unresolved apart from agreeing to try to fix it later
rather than now).

I expect you'll notice that if you change your code the bit of your
app that was causing this problem runs as if you hadn't made the
change at all.
As to what is holding onto an old instance of a class, that can be a
bit hard to track down. I'd go back to the line of code that
originally called the problem. Where does the instance of question
that was causing the problems come from ?