Closed hmmr closed 3 years ago
Thanks. As with the other this issue is resolved when running on 23+ but I guess this solution is simple enough that I can't say no to the change.
This code will go away when 23.1 is the oldest OTP we support, but that won't be for a long time.
Oh, facepalm on windows it tries to compile rebar3 and I don't think that work son otp-19 anymore. I say we just remove windows otp-19 (and may as well remove otp-20) while adding otp-24.
Sorry its not related to your actual PR, but do you mind slipping that in here as another commit? It may be faster than me getting a new PR created, reviewed and merged with the change.
Just change otp_version: [19, 20, 22, 23]
to otp_version: [22, 23, 24]
in .github/workflows/wintest.yml
hah. Gleam's stuff for windows doesn't have 24 yet.
Instances of nodetool generate random node name prefixes to facilitate running multiple simultaneous calls in parallel. However, each time nodetool connects to the target node, a new atom is created on the latter. If this happens frequently and/or long enough, it will eventually crash the node as it hits the atom table limit. As a workaround, if the caller can guarantee calls are serialized and isolated in time, defining an env variable $NODETOOL_NODE_PREFIX will create identical atoms for node name prefix, thus avoiding generation of new atoms.
The proposed change is complimentary to https://github.com/erlware/relx/pull/868, aiming to address the issue, reported by one of our customers, in which a riak node hit the atom table limit (yes, all of 1M+ entries) and crashed. A postmortem showed the table filled with
maint1a2b3c4d-riak@127.0.0.1
, accumulated over a period of time resulting from calls toriak admin status
every 5 min.Note that I did not attempt to do any changes that may need to be done, to the same effect, in extended_bin_windows, as it's not straightforward for me which they would be (my knowledge of scripting in Windows is some 30 year old).