We run a production service on Heroku
◦ Playframework 1.2.5
◦ Multiple dynos
Sometimes following error is logged, when dyno is
◦ This error happens when play receives a request after
◦ But frequency is very rare.
I've discussed about this problem with Heroku
This document explains its detail.
play.exceptions.UnexpectedException: Application is not started
At the shutdown time, Play does nothing to Netty.
After app shutdowned, Netty still alive and can accept
new request.(But always returns 503)
When shutdown process takes a few seconds, there is
a possibility to accept new request and return 503.
Normally this duration is
nearly zero sec.
But rarely takes a few seconds.
Heroku router may send a request after SIGTERM.
◦ When it failed to connect, the request send to other
◦ When it received 503, it is accepted.
◦ Play should stop Netty before app shutdown.
◦ There is no way to stop Netty by application developer.
◦ Heroku shouldn’t send request after SIGTERM.
◦ It is out of control for application developer.
Though it may be possible to fix playframework,
it is better to handle this problem by Heroku side.
(Because other framework may have same problem.)
This is a great feature of Heroku labs.
Preboot changes Heroku restarting behavior
◦ Before: Kill old dynos, then boot new dynos.
◦ After: Boot new dynos first.
◦ Web dynos only
◦ At least two web dynos are required.
◦ git push
◦ heroku config:set
◦ heroku restart
It doesn’t apply at cycling…
Currently there is no way to avoid this
Our service features.
◦ Mostly used in Japan.
◦ So at the midnight(JST), its traffic is not so high.
If I can control the time of cycling to
midnight(JST), it may reduce error possibility.
◦ Though original frequency is not so high, I want to
reduce error possibility as much as possible.
It installs Heroku Toolbelt to dyno.
So it allows one to run heroku command by
Daily at 18:30 (3:30 JST)
◦ vendor/heroku-toolbelt/bin/heroku restart web.1 -a xxx
Daily at 19:00 (4:00 JST)
◦ vendor/heroku-toolbelt/bin/heroku restart web.2 -a xxx
Delay the timing of restarting multiple dynos.
This settings can reduce daytime cycling.
But it doesn't mean the daytime cycling will never
e.g. if Heroku detects a fault in underlying
hardware, it will be cycling.
To solve this problem radically, I hope Heroku
to either of following.
◦ Don’t send request to dyno after SIGTERM.
◦ Apply preboot at cycling.