11–20 of 43 posts
I never understood what in that lib was causing the leak but I fixed it (or more accurately mitigated it) by wrapping the call in a Task.async/1
Maybe that will help someone else one day.
recon and observer_cli are the tools I reach out first to debug any issues in production. In any other language, I usually think about how to reproduce the issue locally. With Elixir, I just get into a remote shell in the affected machine and live debug the issue, and there are cases where we applied hotfix by using eval right there from the shell. The idea of the remote shell itself is alien to most languages.
And unfortunately the kind of thing that compliance flags as a big no-no once you've got any kind of filing or privacy requirements.
Earlier quoted context omitted.
And unfortunately the kind of thing that compliance flags as a big no-no once you've got any kind of filing or privacy requirements.
This sort of thing doesn’t have to be a compliance breach, but you will likely need some way of ensuring there’s a second person in the loop, typically that would take the form of having someone in a separate production infrastructure team actually driving a while you talk them through what needs to happen.
I'm not criticizing the methodology as much as the useless performative nature of compliance work.
Hard to say without knowing much about the data in question, but my recollection is that large Erlang/Elixir/BEAM "binaries" are actually not copied around. That might be a strategy for sharing larger things in some cases.
Marshalling data is pretty easy in Erlang:
2> Bin = erlang:term_to_binary([1, 2, 3]).
>
3> erlang:binary_to_term(Bin).
[1,2,3]> Second, we passed one particularly large data structure from a manager to a pool of dedicated worker processes. This meant we were reincurring the memory cost of this data structure for each worker process. We couldn't eliminate the repetition, but reducing the data to its bare essentials before passing it down to the workers minimizes that cost. Hard to say without knowing much about the data in question, but my r…
Earlier quoted context omitted.
This sort of thing doesn’t have to be a compliance breach, but you will likely need some way of ensuring there’s a second person in the loop, typically that would take the form of having someone in a separate production infrastructure team actually driving a while you talk them through what needs to happen.
Yes and with the added benefit of having to explain that control to your rotating bunch of compliance people every single year. I'm not criticizing the methodology as much as the useless performative nature of compliance work.
1. We had a breach. A factor in this was insufficient oversight on a process that granted privileged access to customer data. We fixed the problem, promise that your data is safe, and don't believe this will happen again.
2. We had a breach. A factor in this was due to a gap in an existing control around customer data that had a problem we had not anticipated. These were the people involved. This is exactly how this problem occurred. This is the data that was exposed. This is documentation of our response to this incident. This is our existing policy around how we handle data and how we respond to breaches.
Customers, partners, regulators, and law enforcement respond a lot better when you can demonstrate good intent and at least imply that you have some kind of process. Of the two scenarios I outlined, the latter provides those assurances.
Compliance isn't the only way to do this, but it's often the easiest.
This is really cool. We use Elixir at work, but we mostly use it in a "traditional web app" (i.e. non-Elixir) way, of Docker containers deployed to independent AWS instances. So I'm always intrigued by some of the more BEAM-specific things that folks do, like using `observer` on a remote (production??) node here, or distributed Elixir where the nodes communicate with each other, or "hot" code updates. How do companie…
Hot code updates for most applications aren't really worth it in my opinion, assuming you do something like blue/green rollover deployments. It's cool that it's possible though. But it requires appup files and afaik Distillery is one of the release tools that has support for it built-in.
This is really cool. We use Elixir at work, but we mostly use it in a "traditional web app" (i.e. non-Elixir) way, of Docker containers deployed to independent AWS instances. So I'm always intrigued by some of the more BEAM-specific things that folks do, like using `observer` on a remote (production??) node here, or distributed Elixir where the nodes communicate with each other, or "hot" code updates. How do companie…
This is really cool. We use Elixir at work, but we mostly use it in a "traditional web app" (i.e. non-Elixir) way, of Docker containers deployed to independent AWS instances. So I'm always intrigued by some of the more BEAM-specific things that folks do, like using `observer` on a remote (production??) node here, or distributed Elixir where the nodes communicate with each other, or "hot" code updates. How do companie…