I'm about to put a CCL web app (using Hunchentoot) into production. Up to now I've been taking advantage of all the interactive goodness that the IDE offers, but of course that will mostly go away once the app is deployed. But it occurred to me that I could use the "screen" program to keep a REPL around for debugging the live app. My question is: is this a wise thing to do? Are there potential unexpected negative consequences of deploying an application this way? Security holes? Possible crashes? Has anyone tried this? This is one set of lessons I'd rather not learn the hard way.
Thanks, rg
Am 02.09.2013 01:04, schrieb Ron Garret:
I'm about to put a CCL web app (using Hunchentoot) into production. Up to now I've been taking advantage of all the interactive goodness that the IDE offers, but of course that will mostly go away once the app is deployed. But it occurred to me that I could use the "screen" program to keep a REPL around for debugging the live app. My question is: is this a wise thing to do? Are there potential unexpected negative consequences of deploying an application this way? Security holes? Possible crashes? Has anyone tried this? This is one set of lessons I'd rather not learn the hard way.
Thanks, rg
On my blog (uxul.de) I did exactly this, with SBCL. However, I ran into the problem that if something elementary that Hunchentoot does not catch goes wrong (OOM, etc.), the REPL of SBCL will drop me into ldb, instead of just stopping (so I can restart it externally). As I do not know how to prevent this, I do not use the REPL anymore.
(As a side note, I prefer using tmux instead of screen. It comes from the OpenBSD world and is _really_ stable.)
MfG CSS
Christoph-Simon Senjak css@uxul.de writes:
Am 02.09.2013 01:04, schrieb Ron Garret:
I'm about to put a CCL web app (using Hunchentoot) into production. Up to now I've been taking advantage of all the interactive goodness that the IDE offers, but of course that will mostly go away once the app is deployed. But it occurred to me that I could use the "screen" program to keep a REPL around for debugging the live app. My question is: is this a wise thing to do? Are there potential unexpected negative consequences of deploying an application this way? Security holes? Possible crashes? Has anyone tried this? This is one set of lessons I'd rather not learn the hard way.
Thanks, rg
On my blog (uxul.de) I did exactly this, with SBCL. However, I ran into the problem that if something elementary that Hunchentoot does not catch goes wrong (OOM, etc.), the REPL of SBCL will drop me into ldb, instead of just stopping (so I can restart it externally). As I do not know how to prevent this, I do not use the REPL anymore.
For what it's worth, you can disable it with this:
(sb-alien:alien-funcall (sb-alien:extern-alien "disable_lossage_handler" (function sb-alien:void)))
You can also build a version of SBCL with ldb omitted with some build-time configuration.
Zach
Ron Garret ron@flownet.com wrote:
I'm about to put a CCL web app (using Hunchentoot) into production. Up to now I've been taking advantage of all the interactive goodness that the IDE offers, but of course that will mostly go away once the app is deployed. But it occurred to me that I could use the "screen" program to keep a REPL around for debugging the live app. My question is: is this a wise thing to do? Are there potential unexpected negative consequences of deploying an application this way? Security holes? Possible crashes? Has anyone tried this?
I've been using "screen" wrapped around Lispworks REPLs for many years without any problems. I mostly use the REPL for loading patches while the server is running. I do most of my debugging in a separate test version that doesn't interact with the production database and is not visible to the outside world.
Arthur
On Mon, Sep 2, 2013 at 11:29 AM, Arthur Lemmens alemmens@xs4all.nl wrote:
Ron Garret ron@flownet.com wrote:
I'm about to put a CCL web app (using Hunchentoot) into production. Up to now I've been taking advantage of all the interactive goodness that the IDE offers, but of course that will mostly go away once the app is deployed. But it occurred to me that I could use the "screen" program to keep a REPL around for debugging the live app. My question is: is this a wise thing to do? Are there potential unexpected negative consequences of deploying an application this way? Security holes? Possible crashes? Has anyone tried this?
I've been using "screen" wrapped around Lispworks REPLs for many years without any problems. I mostly use the REPL for loading patches while the server is running. I do most of my debugging in a separate test version that doesn't interact with the production database and is not visible to the outside world.
Back in the bad old days, araneida+cliki was typically deployed using detachtty, which can be thought of as a very reduced variant of screen specialized for demonificaion. These days, I use screen for a variety of daemons.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It’s amazing that the amount of news that happens in the world everyday always just exactly fits the newspaper.
On Sep 1, 2013, at 7:04 PM, Ron Garret ron@flownet.com wrote:
I'm about to put a CCL web app (using Hunchentoot) into production. Up to now I've been taking advantage of all the interactive goodness that the IDE offers, but of course that will mostly go away once the app is deployed. But it occurred to me that I could use the "screen" program to keep a REPL around for debugging the live app. My question is: is this a wise thing to do? Are there potential unexpected negative consequences of deploying an application this way? Security holes? Possible crashes? Has anyone tried this? This is one set of lessons I'd rather not learn the hard way.
I'm currently using "emacs --daemon" s a wrapper for this kind of thing. Crazy eh?
On 09/01/2013 04:04 PM, Ron Garret wrote:
I'm about to put a CCL web app (using Hunchentoot) into production. Up to now I've been taking advantage of all the interactive goodness that the IDE offers, but of course that will mostly go away once the app is deployed. But it occurred to me that I could use the "screen" program to keep a REPL around for debugging the live app. My question is: is this a wise thing to do? Are there potential unexpected negative consequences of deploying an application this way? Security holes? Possible crashes? Has anyone tried this? This is one set of lessons I'd rather not learn the hard way.
Thanks, rg
Why not just connect to it through swank? I do that all the time with my remote webserver. SSH into the server, bring up emacs and slime-connect and you're running under the live instance.
--Jeff
On Mon, Sep 2, 2013 at 12:52 AM, Jeffrey Cunningham jeffrey@jkcunningham.com wrote:
Why not just connect to it through swank? I do that all the time with my remote webserver. SSH into the server, bring up emacs and slime-connect and you're running under the live instance.
Or even better, open an ssh tunnel into the server and slime-connect from the comfort of your local Emacs.
On 09/01/2013 05:00 PM, Luís Oliveira wrote:
On Mon, Sep 2, 2013 at 12:52 AM, Jeffrey Cunningham jeffrey@jkcunningham.com wrote:
Why not just connect to it through swank? I do that all the time with my remote webserver. SSH into the server, bring up emacs and slime-connect and you're running under the live instance.
Or even better, open an ssh tunnel into the server and slime-connect from the comfort of your local Emacs.
I was going to say that, but I've only done it a few times. While I much prefer using my local emacs I have to be careful modifying and compiling on my local source getting out of sync with the remote source.
On Sep 2, 2013, at 7:28 AM, Jeffrey Cunningham jeffrey@jkcunningham.com wrote:
On 09/01/2013 05:00 PM, Luís Oliveira wrote:
On Mon, Sep 2, 2013 at 12:52 AM, Jeffrey Cunningham jeffrey@jkcunningham.com wrote:
Why not just connect to it through swank? I do that all the time with my remote webserver. SSH into the server, bring up emacs and slime-connect and you're running under the live instance.
Or even better, open an ssh tunnel into the server and slime-connect from the comfort of your local Emacs.
I was going to say that, but I've only done it a few times. While I much prefer using my local emacs I have to be careful modifying and compiling on my local source getting out of sync with the remote source.
So I've been working as the CTO of a company called Cleartrip for about a year. I've been trying to make "continuous deploys" work. One thing about this in the Java+Ruby environment we're using (not my call, pre-existing stack) is that packaging up these constant little incremental changes that have to be rolled put to 10s or 100s of servers is not trivial.
It seems to me that it should be possible to build a secure Slime solution that "fans out" incremental changes to a whole (sub-)farms of servers. A CL library build on top of Slime that manages continuous deployment would be pretty awesome.
Does it already exist?
-
Arthur Lemmens -
Ben Hyde -
Christoph-Simon Senjak -
Faré -
Jeffrey Cunningham -
Luís Oliveira -
Ron Garret -
Scott McKay -
Zach Beane