Strange production vs. development behavior difference

I am running into something that has me stunned.

I have a wizard like application that works perfectly well in
development but does not in production. The code has nothing
environment specific going on and the same DB is used in both modes so
I know the problems are not being caused by the data.

The specific problem I have is that I am supposed to display a section
of the page only if the same SSN is in the DB already. The SSN is
already in the DB so the page should always display.

The funny thing is that the page works as expected for both creation
and update in development but only for creation in production.

Furthermore, there is something really funky going on. If I add this
at the beginning of my action:

render :text => 'in my action'
return

the development environment will execute it with no problem but the
production environment completely ignores. It is like if I had made no
changes to the code. And in case you were going to ask, yes I made
sure (about 10 times) that the web server (Mongrel) had been restarted
when running in production.

I have been looking around the whole day and I can’t find anything
that would give me a clue about what the problem might be.

Any help would be greatly appreciated.

Rails is NOT installed in vendors
Ruby: 1.8.6
Gems:
*** LOCAL GEMS ***

actionmailer (2.3.5, 2.2.2)
actionpack (2.3.5, 2.2.2, 1.13.6, 1.13.3)
actionwebservice (1.2.6, 1.2.3)
activerecord (2.3.5, 2.2.2, 1.15.6, 1.15.3)
activerecord-oracle-adapter (1.0.0.9250)
activerecord-oracle_enhanced-adapter (1.2.3)
activeresource (2.3.5, 2.2.2)
activesupport (2.3.5, 2.3.3, 2.2.2, 1.4.4, 1.4.2)
archive-tar-minitar (0.5.2)
builder (2.1.2)
calendar_date_select (1.15, 1.13)
cgi_multipart_eof_fix (2.5.0)
color (1.4.0)
cucumber (0.6.2)
diff-lcs (1.1.2)
fastthread (1.0.1)
fxri (0.3.6)
fxruby (1.6.6)
gem_plugin (0.2.3)
hoe (1.8.2)
hpricot (0.4)
ibm_db (1.1.1)
json_pure (1.2.0)
linecache (0.43)
log4r (1.0.5)
mongrel (1.1.5)
mysql (2.7.3)
paginator (1.1.1)
pdf-writer (1.1.8)
polyglot (0.2.9)
rack (1.0.1)
rails (2.3.5, 2.2.2)
rake (0.8.7, 0.8.3)
rspec (1.3.0)
ruby-debug-base (0.10.3, 0.10.2)
ruby-debug-ide (0.4.5, 0.3.1)
rubyforge (1.0.3, 1.0.2, 1.0.1)
rubygems-update (1.3.5, 1.3.1)
sources (0.0.1)
sqlite3-ruby (1.2.1)
term-ansicolor (1.0.4)
transaction-simple (1.4.0)
treetop (1.4.3)
win32-clipboard (0.4.1)
win32-dir (0.3.1)
win32-eventlog (0.4.3)
win32-file (0.5.3)
win32-file-stat (1.2.3)
win32-process (0.5.1)
win32-sapi (0.1.3)
win32-sound (0.4.0)
win32console (1.2.0)
windows-pr (0.6.2)

On Thu, Feb 18, 2010 at 7:50 PM, pepe [email protected] wrote:

production environment completely ignores. It is like if I had made no
changes to the code. And in case you were going to ask, yes I made
sure (about 10 times) that the web server (Mongrel) had been restarted
when running in production.

I have been looking around the whole day and I can’t find anything
that would give me a clue about what the problem might be.

Any help would be greatly appreciated.

Pepe, as of Rails 2.3.5, the difference between the production and
development environments
are as follows:

  • caching (by default)

    • development: Off
    • production: On
  • reloading of models, views, and controllers on each request (by
    default)

    • development: On
    • production: Off

Good luck,

-Conrad

Thanks Conrad,

I knew about the caching and reloading differences, that is the reason
I have been stopping and starting the web server every time while
debugging the production environment. My understanding is that the web
server will work with the application as if it were the first time it
“saw” it every time it is re-started. If that is true, why doesn’t it
take the changes I make to my action? Is there something else I should
do or look up that might be causing this behavior? Has anybody
encountered a similar problem? If there is something kept “in memory”
that might be causing the problem, where to look?

Thank you.

Pepe

These kind of errors normally belong to the “editing the wrong file”
bag. Can you double-check that the render :text is there with less(1)
in the production machine? That that tree is the one being served?
That you are pointing your browser to the correct machine?

On Feb 19, 4:17 pm, pepe [email protected] wrote:

was probably being processed by Rails after the newer one was and the
definition of the class was most likely being overlaid.

What I don’t understand now is why when I changed the newer version of
the controller Rails took the changes in the development environment.
Shouldn’t the controller class have been always replaced by the older
version even in development? I wish I knew more about the internal of
Rails to understand this. There is so much to learn…

Classes are loaded in different ways in production versus development

  • in particular in production it will load pretty much every file in
    your app on startup, whereas in development it loads things as needed
    (and this mechanism would never cause foo_controller_save.rb to be
    loaded (unless you wrote FooControllerSave in your app.).

Fred

Xavier,

I had thought about that long ago and I was sure I was working with
the right application. I don’t have any other application with the
same name anywhere in the system and the changes I was making to the
views for debugging purposes were being processed just fine.

However… I had a copy of the old controller file in the controllers
folder. I had given it the same name and appended ‘_save’ at the end.
And that is what the problem was. The old version of the controller
was probably being processed by Rails after the newer one was and the
definition of the class was most likely being overlaid.

What I don’t understand now is why when I changed the newer version of
the controller Rails took the changes in the development environment.
Shouldn’t the controller class have been always replaced by the older
version even in development? I wish I knew more about the internal of
Rails to understand this. There is so much to learn…

Your comment made me remember that the class name in both files was
still the same and since classes are never closed in Ruby that should
be causing the problem. I removed the older version of the controller
form the controllers folder and now it all works as expected.

Thank you very much!

Pepe

Thanks Fred, that explains it.

Thank you very much to all of you for your help.

Pepe

On Feb 19, 11:28 am, Frederick C. [email protected]