all heroku apps: queue, scheduler, auth, index, mozilla-taskcluster, events

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
4 years ago
3 years ago

People

(Reporter: jlal, Unassigned)

Tracking

Details

(Reporter)

Description

4 years ago
Use "forever" or something similar to manage app crashes to bypass heroku exponential retries.
(Reporter)

Comment 1

4 years ago
We should also alert when we are down for N minutes (N should be configurable).
Summary: all heroku apps: → all heroku apps: queue, scheduler, auth, index, mozilla-taskcluster, events
I'm not sure this works for anything but background processes, see:
https://devcenter.heroku.com/articles/error-codes#r10-boot-timeout

Basically, heroku will crash an app if it doesn't start listen to $PORT within 60s.
Sure we could setup a reverse proxy manager too, but they heroku router can't guide requests around
the dynos that are restarting. Which dynos do every 24 hours.
The point having multiple dynos is that restarts don't necessarily drop connections.

At the end of the day, I think doing this is fighting heroku, which is probably the wrong thing to do.
I believe we agreed to close this because it can't be done right, See Comment 2.

Some day we'll probably move heroku apps to a docker based platform and this won't be an issue.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
Component: TaskCluster → General
Product: Testing → Taskcluster
Target Milestone: --- → mozilla41
Version: unspecified → Trunk
Resetting Version and Target Milestone that accidentally got changed...
Target Milestone: mozilla41 → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.