Upgrade Aspen

[Changaco]

@whit537 I need your help on this one.

[chadwhitacre]

The biggest change is that we'll need to install uwsgi or gunicorn or something (#1868) and start using that, because in 0.31 we ripped out Aspen's built-in app server.

[chadwhitacre]

I'm looking at this.

[chadwhitacre]

Using either uswgi or gunicorn, I get an error trying to connect to postgres.

[chadwhitacre]

It's difficult to debug because I can't get to pdb because of the process boundary.

[chadwhitacre]

psql connects just fine.

[Changaco]

Rebased on master and added the commit to remove our temporary copy of to_rfc822().

[chadwhitacre]

Rebased on master.

[chadwhitacre]

@Changaco So the reason this is going slower than expected is because we made changes affecting JSON simplates. We did away with JSON simplates as a special case; now they're regular simplates that use a json_dump renderer. I'm upgrading our JSON simplates to use this new pattern.

[chadwhitacre]

cc: @pjz

[Changaco]

@whit537 That's okay, this PR isn't blocking anything else now, so there's no rush to land it.

[chadwhitacre]

There are some JSON files that must not be covered by the test suite, because with that last commit I fixed all the SyntaxErrors I was seeing, and there are *.json.spt files that I didn't touch there.

[chadwhitacre]

@Changaco Your additional commits look good so far. Still need to sort out js tests, looks like?

[chadwhitacre]

IRC

[chadwhitacre]

I'm debugging the Gruntfile gunicorn killing issue.

[chadwhitacre]

The problem is that when the aspen:start task completes, the gunicorn parent is orphaned. It should be terminated.

[chadwhitacre]

Hypothesis: the SIGTERM never makes it from grunt (node) to the child process (honcho).

Test: Stub out a server.py with a SIGTERM handler and see if it terminates.

[chadwhitacre]

#!/usr/bin/env python
import signal
import sys
import time

out = open('foo.log', 'w+')

def handler(signum, frame):
    print >> out, 'Killed!'
    raise SystemExit

signal.signal(signal.SIGTERM, handler)


slept = 0
while 1:
    print >> out, "Still here."
    time.sleep(0.3)
    slept += 1
    if slept == 3:
        print >> sys.stderr, "Starting gunicorn "

[chadwhitacre]

Result: No! The server process does receive the SIGTERM from node.

[gittip] $ ./node_modules/.bin/grunt aspen:start
Running "aspen:start" task
Starting Aspen... started.

Done, without errors.
[gittip] $ cat foo.log
Still here.
Still here.
Still here.
Still here.
Still here.
Still here.
Still here.
Killed!
[gittip] $

[chadwhitacre]

Here's a demonstration of the problem:

$ ps ww|grep gunicorn
79870 s005  S+     0:00.00 grep gunicorn
$ ./node_modules/.bin/grunt aspen:start
Running "aspen:start" task
Starting Aspen... started.

Done, without errors.
$ ps ww|grep gunicorn
79873 s005  S      0:00.25 /Users/whit537/personal/gittip/www.gittip.com/env/bin/python2.7 ./env/bin/gunicorn aspen.wsgi:website
79876 s005  S      0:00.42 /Users/whit537/personal/gittip/www.gittip.com/env/bin/python2.7 ./env/bin/gunicorn aspen.wsgi:website
79879 s005  R+     0:00.00 grep gunicorn
$

[chadwhitacre]

We're calling honcho from grunt. We are reasonably certain that honcho is receiving the SIGTERM, because we know that a stub server.py does. Also, honcho is gone! The problem seems to be that honcho does not propagate SIGTERM to children when it receives one itself.

[chadwhitacre]

Relevant: nickstenning/honcho#32.

[chadwhitacre]

Oh well. Worked on nickstenning/honcho#32 for a while and gave up.

Ready on this PR when you are, @Changaco.

[Changaco]

I tried to deploy this, it didn't work, so I looked for potential problems and made some changes, but it still doesn't work. The heroku error we're getting is H20 App boot timeout.

[Changaco]

Problem solved. IRC.