this is a temporary fix for #32.
it doesn't solve the problem, but it makes the renders much less worse.
in combination with #134 this will hopefully lead to fixing the problem entirely
this was originally implemented because we wanted to delete the oldest images on disk
where 'oldest' means not *used* for the longest time
that's not useful and was never actually implemented, so we don't need this
afaik you can have persistent storage on heroku, at least via addons
and heroku is probably not the only environment where one has a temporary file system
I think this makes more sense, especially when you run multiple instances
so they can use the same image cache instead of each version relying on their own
should be up to the user where to put log files
and to make sure that directory actually exists
currently nothing in this code base expects
logs/ to be present.
this will close the server, i.e. all new connections will be dropped
while existing connections are able to complete within 30 seconds
otherwise they are dropped and the server force quits
From the iojs docs:
> An unhandled exception means your application - and by extension io.js itself -
> is in an undefined state. Blindly resuming means anything could happen.
>
> Think of resuming as pulling the power cord when you are upgrading your system.
> Nine out of ten times nothing happens - but the 10th time, your system is bust.
>
> uncaughtException should be used to perform synchronous cleanup before shutting
> down the process. It is not safe to resume normal operation after
> uncaughtException. If you do use it, restart your application after every
> unhandled exception!
