I am working on a Rails 3.0 application, and I just made a change to an
erb view template, reloaded the page in my browser (from the server, not
development) and the change was instantly available. This tells me that
the template isn’t being pre-cached, and I can’t see why. I’ve looked
through the production environment file, there are no configuration
statements that leap out at me regarding this, and I am certain that I
have had to restart my application in order for view changes to be
picked up in the past. Can anyone suggest a place to look where this
behavior might be overridden?
Thanks,
Walter
On Thursday, April 3, 2014 10:30:48 AM UTC-4, Walter Lee D. wrote:
Thanks,
Walter
would need to know your server environment. We use passenger. when we
deploy, it touches the file /tmp/restart.txt, changing the date/time
stamp
on the file. Passenger picks this up and automatically reloads the
application when that has changed. It is possible to configure
Passenger
to always do that regardless of the timestamp, but obviously you would
be
taking a significant performance hit.
On Apr 3, 2014, at 11:20 AM, mike2r wrote:
On Thursday, April 3, 2014 10:30:48 AM UTC-4, Walter Lee D. wrote:
I am working on a Rails 3.0 application, and I just made a change to an erb view
template, reloaded the page in my browser (from the server, not development) and
the change was instantly available. This tells me that the template isn’t being
pre-cached, and I can’t see why. I’ve looked through the production environment
file, there are no configuration statements that leap out at me regarding this,
and I am certain that I have had to restart my application in order for view
changes to be picked up in the past. Can anyone suggest a place to look where this
behavior might be overridden?
Thanks,
Walter
would need to know your server environment. We use passenger. when we deploy,
it touches the file /tmp/restart.txt, changing the date/time stamp on the file.
Passenger picks this up and automatically reloads the application when that has
changed. It is possible to configure Passenger to always do that regardless of
the timestamp, but obviously you would be taking a significant performance hit.
Also using Passenger, with Apache 2.2. Have never made any such
configuration changes – deploy the same way on all sites I’ve ever
done, and I also use the restart.txt trick to roll the server. I can
confirm that that file is not being touched when I upload new code. I am
concerned that I am taking such a performance hit, and I’d like to stop
that, naturally.
Looking into this, I see my Ruby and Passenger are quite out of date.
Recompiling now, let’s see if that helps any.
Thanks,
Walter
On Apr 3, 2014, at 11:53 AM, Walter Lee D. wrote:
Walter
would need to know your server environment. We use passenger. when we deploy,
it touches the file /tmp/restart.txt, changing the date/time stamp on the file.
Passenger picks this up and automatically reloads the application when that has
changed. It is possible to configure Passenger to always do that regardless of
the timestamp, but obviously you would be taking a significant performance hit.
Also using Passenger, with Apache 2.2. Have never made any such configuration
changes – deploy the same way on all sites I’ve ever done, and I also use the
restart.txt trick to roll the server. I can confirm that that file is not being
touched when I upload new code. I am concerned that I am taking such a performance
hit, and I’d like to stop that, naturally.
Looking into this, I see my Ruby and Passenger are quite out of date.
Recompiling now, let’s see if that helps any.
Thanks,
Walter
Thanks for the nudge. Ruby and Passenger re-compile did the trick.
Getting the expected behavior now, also quite a bit snappier (although
that could just be less traffic for the moment what with restarting a
bunch of times).
Walter