My app sometimes crashes and I would like to know if there is a Add-on or Dyno that I can deploy which will detect when my app is crashed and restart is automatically.
There's no add-on which will auto-deploy your crashed app on heroku, but here's a work around.
Use a log-management add-on(like papertrail)
Watch out for log messages you get when your heroku app crashes.
Add custom web-hooks that gets triggered whenever you app gives one of those error-logs that correspond to an app crash.
Make these web-hooks to call a custom service that redeploys your application. https://help.papertrailapp.com/kb/how-it-works/web-hooks/
When you encounter an "app crash" situation, it usually means only the "web dyno" is crashed. Your service workers might still be running. Though this approach answers your query, I would recommend not to use it in practice because you would want to manually see you logs, find the reason for app-crash and fix it so you don't have to face it in future.
Related
I want just 1 trade open at a time. But Heroku force my bot to open another trade each time my bot "crashes" because Heroku restarting my bot again.
How can avoid this and "tell" Heroku to doing nothing if I already have an open trade?
I had to turn off the web dynos
This is not Heroku's fault. Heroku will always try to keep you application up, that's the deal with using such services. So if it crashes, it will restart.
You should check on your own application to only open a trade if there isn't one already.
My use case is the following - being able to periodically send updates to a web service with the current location of the device on which the {NS} app is running. This should happen even if the app is "minimized".
I saw that workers have been added to the framework, but as I understand it, the app is supposed to be active(not minimized) for the worker to execute.
Is there a way to accomplish this?
Cheers
You need to use background-services for this purpose.
NativeScriptBackgroundServices
My Question:
If I see these lines in heroku logs, does that imply that preboot is disabled? If not, why not?
2015-02-04T14:48:00.674205+00:00 heroku[web.1]: State changed from up to starting
2015-02-04T14:48:00.720515+00:00 heroku[web.2]: State changed from up to starting
My understanding is that preboot should fire up brand new dynos, get them ready to serve requests, start routing requests to them, then shut down the old dynos. Nowhere in that process would I imagine dynos changing from up to starting.
The Background:
I'm working on a deploy script that automatically toggles preboot depending on whether any database changes will be made. In testing the script, I'm watching the logs hoping to determine whether preboot is actually being used when it should. I see preboot turning on in the console output of my script:
Enabling preboot for <snip>... done
Yet in the logs I am seeing what I pasted at the top. I'm trying to reconcile these facts.
One way to verify this is to watch the dyno ID number change. You can see the dyno ID by adding log-runtime-metrics to your app.
source=web.1 dyno=heroku.2808254.d97d0ea7-cf3d-411b-b453-d2943a50b456 sample#load_avg_1m=2.46 sample#load_avg_5m=1.06 sample#load_avg_15m=0.99
You can watch for that "dyno" value to change once the new dynos are accepting requests.
I have an app deployed on meteor.com, which after 2-5 days of working perfectly suddenly becomes unresponsive to requests. Restarting the app by deploying it again causes it to work properly.
What's the best way to debug this? I don't know how to reproduce the issue on my local server since it only happens intermittently.
Nothing seemed off in meteor logs other than this line:
spiderable: phantomjs failed: { [Error: Command failed: ] killed: true, code: null, signal: 'SIGTERM' } stderr:
I tried removing the spiderable smart package and the issue still occurs.
Meteor.com's hosting via meteor deploy will kill your app if its not visited for somewhere near 2-4 hours.
This doesn't mean that its dead though, if you load it up in your web browser it'll take a couple of seconds extra to get running again. It might take longer if you have a heavy startup load, though.
Meteor hasn't brought up details of its paid solutions yet, but if you want to keep your site up for longer it should automatically if it has a visit every hour or two. I'm not suggesting that its the best way to do it, but you could remotely ping it too.
Is there any potential downtime when I do a commit to a clojure/Java app running on Heroku?
I am guessing not - but can't find out for sure.
Thanks.
When you push to Heroku, you invoke the slug compiler, which does all the heavy lifting needed to turn your application into a self-contained archive. That can take a little while, as you see whenever you run git push. However, during this time, your application is running normally.
When your slug finishes compiling, Heroku then pushes it out to the dyno grid. This causes existing web dynos to stop and causes new ones to start. Your application will be unresponsive between the time that the old dynos stop and the new ones begin serving requests -- probably only a few seconds. During this interval, Heroku's routing layer will queue incoming requests.
TL;DR: users might notice a pause (but not an error!) as your application is updated. You can simulate this at any time by running heroku restart.