Re: Deploying patches to running web apps

Christophe Rhodes <csr21@xxxxxxxxx> writes:

> Petter Gustad <newsmailcomp6@xxxxxxxxxx> writes:
>
> > "Jonathon McKitrick" <j_mckitrick@xxxxxxxxxxx> writes:
> >
> >> What are some proven approaches to deploying patches to applications
> >> that should not be stopped and restarted?
> >
> > In Allegroserve you can just compile the new funcion in the REPL or
> > simply typing C-C C-C inside the function in Emacs if you're using
> > SLIME. Also see news:87mzhlwdf5.fsf_-_@xxxxxxxxxxxxxxxxxxxxxx
>
> This is the traditional answer (not just in Allegroserve, but in most
> lisp applications), but sometimes I wonder. Consider
>
> (defun foo (a)
> (bar (frob a)))
>
> Now suppose that you need to change both bar and frob: say you need to
> return more information to bar frob (an extra element in a list, say).
> How do you do this safely, without stopping the application? I don't
> think it's as simple as typing C-c C-c twice, or compiling "the new
> function" in the repl, because doing so introduces inconsistencies in
> code which might be running -- it would be bad if an application
> thread is running in the old FROB when you compile the new BAR.

The missing nuance in the traditional answer is that you should be
doing this on your testing server, not directly in production. Once
you have your patch worked out, I bet most people just load the fasl
into the running server image, and hope that no one makes a request at
just the wrong moment.

On the other hand, CMUCL developers are quite used to bootstrapping
changes into their running system, so maybe they tend to do this
right. If the bootstrapping gets tricky, I personally punt and just
hot-swap the server itself.

--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
.

Loading