aungmyooo2k17
In Elixir umbrella apps, when an error occurs in one application (e.g., appA) and its supervisor determines that the error cannot be recovered, the supervisor might terminate the entire umbrella application, affecting not only appA but also appB. I want to know how supervisors work within umbrella apps, their fault-tolerance strategies, and how to handle such scenarios effectively.
I check the supervision tree with wxwidget there are two seperate supervisor. But why behaving like killing both apps in my case.
Any link or explanation would be appreciate.
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
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
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
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
Documentation
While reading the Scoped Routes section, I noticed that the documentation currently refers to a problem without explainin...
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
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
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself.
My main conc...
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
- #elixirconf-us
- #ai
- #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 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
adw632
By default if an OTP application crashes, the BEAM will exit. This means your application supervision tree has crashed or failed to start.
By default there is no restarting at the app level, and restart typically needs to be handled outside of the VM, however you can look at Shoehorn from the nerves project which provides app crash recovery within the beam using a different boot setup and an app crash handler module. It also allows you to specify the startup order which can prioritise starting certain apps so they are available sooner.
LostKobrakai
As mentioned there is no supervision for or of applications. If the root process of an application terminates the application will terminate. There’s neither an attempt made to restart the application, nor to restart the root process (the pid returned from
Application.start/2is the root process).What happens as a result of the application terminating depends on its restart type. If
:permanentthe whole vm will shut down, with:transientthe same will happen only if the exit reason of the root process wasn’t:normalotherwise it behaves like:temporary, which means the application termination is reported, but nothing else happens. Application — Elixir v1.20.2The default for your dependencies and all your apps in an umbrella is
:permanent, but you can customize the type in the release settings.Shoehorn builds on top of those things by defaulting all applications to
:temporaryunless explicitly mentioned as an:initapplication, making them permanent and ordering them to start as early as possible.It also integrates with the application termination reporting to allow you to restart applications. I’d however strongly suggest to exhaust other solutions before going with that one.
aungmyooo2k17
Thanks to your help I found out this statement at elixir document.
https://elixir-lang.org/getting-started/mix-otp/config-and-releases.html#releases
As a starting point, let’s define a release that includes both
:kv_serverand:kvapplications. We will also add a version to it. Open up themix.exsin the umbrella root and add insidedef project:That defines a release named
foowith bothkv_serverandkvapplications. Their mode is set to:permanent, which means that, if those applications crash, the whole node terminates. That’s reasonable since those applications are essential to our system.tristan
I think it is important to note that an umbrella is a project layout solution and unrelated to how the program actually runs.