3 ms·
Kind of not surprising that "Large messages between processes" doesn't have a refactored solution :)
by trhway 5y ago
Kind of not surprising that "Large messages between processes" doesn't have a refactored solution :)
- kamray23 5y agoThe whole language as well as this repo really drips and oozes the word "Enterprise" in CamelCase as all good enterprise programs should be. Large messages are just the norm.
- ergl 5y agoIt's weird to see "large messages" as a code smell. I'd say it's more of a thing to be aware about if you use any BEAM-based language: that's just how the runtime works. But, if you're constantly sending large messages between processes, that might be a sign that those two processes are not as independent as you though, and it might be good to think if there's a way to merge them into a single process. Another option might be see if you can transform those messages into ref-counter binaries, which will make sending messages quite cheap, since you're sending a single reference to the binary, instead of the whole thing. There's a tradeoff here, of course, depending on how expensive it is to transform your data into a binary, as well as increased complexity of garbage collection of these binaries.
- pawelduda 5y agoI think this concern/code smell section should be about spamming large messages between processes, in which case the solution could be throttling (but not by the receiving process, as it would still flood its mailbox).