Hacker News Reader

Comment by PuercoPop | Hacker News Reader

One of the things I would have liked to see on the article is how do they handle the deployment itself. Do they build an executable with build app? To they used sb-daemon? An home-grown solution using sb-posix:fork?

View on HN

I don't know how they do it, but I have run several Lisp production systems. I use CCL, which has a really fast compiler. So I just load the code from source. The deployment process then becomes: git pull, quit and restart Lisp. (The ccl-init file loads the code.)

And in that case how do you handle the monitoring of the system?

I don't understand the question. Once it's running, it's like any other server, and you monitor it like you would any other server written in any other language.

Speculation here, but based on the context, I think the question is: Some daemon-izer solutions will monitor the daemon and e.g. restart it if it's unresponsive. How do you handle this slash how is this handled in the Common Lisp world?

As a last resort, if Lisp becomes totally unresponsive, you kill the process and restart, same as any other language. But it's pretty rare to lose the REPL, so usually you can fix any unexpected problems through that.

This is why I switched from running daemons in tmux to having them start a slime listener; I can monitor them from any standard process monitor that will log errors and restart (I use daemontools with a run-script that sends me an e-mail to notify me of the restart).

Oh cool! so from the server you stop the image that's running on the server, then restart the CCL image, and then load in the source (like starting a repl on the server and doing a "load ./start-file.lisp")? (ps sorry for the rookie questions am quite new to this and very interested).

Yes, exactly. (And no worries about rookie questions. That's how people become non-rookies.)

In my case, I run the REPL using screen so I can go back to it for debugging if I need to. But you can also run "headless", without a REPL at all if you want.

How do you deal with existing connections to the Lisp service when you want to deploy?

e.g. remove from load balancer, wait up to n minutes for connections to drain?, git pull, quit, restart Lisp, re-add to load balancer. ?

Yep, pretty much. I've only ever dealt with low-load applications so there was no load balancer. You just put the Lisp server in a state where it refuses new connections (serves up a "temporarily down for mx" page, or reconfigure the ngingx front end to do that), wait for existing connections to finish, and then restart. It's no different from any other server.

There's a reference to upstart in the article. We have played with demonizing SBCL (there are a couple of projects out there), but then Grammarly as a whole moved to upstart-based deployments. They are really easy to manage: basically, you just give it a normal (Lisp) script.

Something I need to get around to doing is playing with Docker and SBCL - it gives you daemonization out of the box. Have you tried that?

Yes, we're in the process of moving to docker-based deployments now. In fact, we already have ClozureCL running inside docker, but haven't yet done the same for SBCL. TBD soon :)

Reply on news.ycombinator.com