2011 Web Scripting Languages and Dynamic Reloading

Question

This has been bugging me for awhile now.

In a deployed PHP web application one can upload a changed php script and have the updated file picked up by the web server without having to restart.

The problem? Ruby, Groovy, & Python, etc. are all "better" than PHP in terms of language expressiveness, concision, power, ...your-reason-here.

Currently, I am really enjoying Groovy (via Grails), but the reality is that the JVM does not do well (at all) with production dynamic reloading of application code. Basically, Permgen out of memory errors are a virtual guarantee, and that means application crash at anytime -- not good.

Ruby frameworks seem to have this solved somewhat from what I have read: Passenger has an option to dynamically reload changed files in polled directories on the next request (thus preventing connected users from being disconnected, session lost, etc.).

Standalone Python I am not sure about at all; it may, like PHP allow dynamic reloading of python scripts without web server restart.

As far as our web work is concerned, invariably clients wind up wanting to make changes to a deployed application regardless of how detailed and well planned the spec was. Telling the client, "sure, we'll implement that [simple] change at 4AM tomorrow [so as to not wreak havoc with connected users]", won't go over too well.

As of 2011 where are we at in terms of dynamic reloading and scripting languages? Are we forever doomed, relegated to the convenience of PHP, or the joys of non-PHP and being forced to restart a deployed application?

BTW, I am not at all a fan of JSPs, GSPs, and Ruby, Python templating equivalents, despite their reloadability. This is a cake & eat it too thread, where we can make a change to any aspect of the application and not have to restart.

Answer 1

You haven't specified a web server. If you're using Apache, mod_wsgi is your best bet for running Python web apps, and it has a reloading mechanism that doesn't require a server restart.

Answer 2

I think you're making a bigger deal out of this than it really is.

Any application for which it is that important that it never be down for 1/2 a minute (which is all it takes to reboot a server to pick up a file change) really needs to have multiple application server instances in order to handle potential failures of individual instances. Once you have multiple application servers to handle failures, you can also safely restart individual instances for maintenance without causing a problem.