darkmarmot
When a supervised process crashes and restarts repeatedly, it can crash its supervisor, which restarts and crashes and at some point it causes the root application supervisor to crash.
This has hit me a couple times now… and I’m wondering if there are some decent ways to deal with this? Is it generally handled with deeper nesting, higher restart thresholds, delayed process actions that could cause errors? Other techniques?
I am basically looking to have part of my application down rather than fully down (so that it can be inspected and/or fixed with hot code loading).
Thanks!
Trending in Questions
I’m working on a project that simulates the bumbl example in the programming phoenix book. It acts almost like an email client. We have a...
New
I’m seeing that a list inside a Kino.DataTable will be interpreted as a charlist, even if the Kino.configure() is set to charlists: :as_l...
New
Hello,
I know there is an approach for handling lists that allows for optimized traversal, but I can’t recall the specific method (somet...
New
So my question is quite simple and i have found no conclusive answer on forum, google or AI.
Should we use :erlang.float for Integer to ...
New
Hi, I’ve just set up an application with ash_authentication. There is only magic link strategy for now, so there is no confirmation add o...
New
If a change or preparation module uses Ash.Changeset.get_argument/2 or Ash.Query.get_argument/2 (or any of the other get_argument functio...
New
apply_graft/2 doesn’t rewrite an add_many sub-workflow’s deps on an add step. Grafted jobs cancel with “upstream job was deleted”
Version...
New
Other Trending Topics
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Hi there! We created Gust: A task orchestrator inspired by Airflow.
For those who have never heard about Aiflow, it’s a Python-based wor...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve.
They are GUI (Emerge) and State management (S...
New
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
You’ll need to handle at least the part of “now stop trying” manually. Supervisors are meant to keep trying – they operate under the assumption that human intervention might need a technician driving to the device.
That’s why you always want something OS level as well like heart or systemd.
darkmarmot
Thanks!
We have a large cluster across multiple data centers that we regularly upgrade. Our main problem has been when incompatible versions of code are released into the cluster. We’re looking for ways to prevent all the nodes from crashing en masse due to a bad mistake in which “bad” data passes between node boundaries.
I’m experimenting now with using configurable
Process.sleepcalls viaGenServer’shandle_continueto throttle process restarts so that repeatings failures have a deterministic upper bound for the crash rate.wolf4earth
What I’ve been doing in the past, in a larger system I’ve worked on, was to introduce another supervision layer, let’s call it the parent supervisor, above the supervisor which supervised the problematic process, let’s call it the child supervisor.
The parent supervisor starts the child supervisor with the
restartoption set totemporary. This way the child supervisor still does it’s job as usual, until sh*t hits the metaphorical fan and it goes down. As it was started astemporarythe parent supervisor won’t restart it, and acts as a circuit breaker.Of course you either need some monitoring on top - so a human operator can step in and fix the problem - or some kind of exponential restart strategy. But at least you’ve now isolated the issue to part of your system.
Hope this helps?
darkmarmot
That sounds like a good as well, thanks!
cmkarlsson
I know there is a really good talk from Fred Hebert about how to design robust systems
I think it is this:
but not sure as I think the graphic was different in the one I am thinking of.
Other useful blogs:
pedromtavares
Your suggestion is precisely what is recommended by the Elixir in Action book: