BCM1982
I am using GenServer.call/3 to send messages from one node (Node A) to another (Node B). The messages must be sent in order, sort of like this:
Enum.map payload, fn load →
GenServer.call({Server,:somewhere@remote},load)
end
However, I want these calls to be very fast. I could create a Task for each call, and have Node A attach a timestamp (represented by ascending natural numbers) to each load so that Node B can sort the potentially out of order messages, like this.
Enum.map payload, fn load →
Task.async(fn → GenServer.call({Server,:somewhere@remote},{Counter.next(),load}) end)
end
|> Enum.map fn task →
Task.await(task)
end
Sorry for any formatting or syntax errors. This should start a process for each call to Node B, and the networking time is overlapped instead of stretched out. The problem with this approach is that now Node A must generate timestamps for messages when Node B is supposed to do so (the system uses star topology with Node B at the center acting as a message broker). I want to keep the design clean. Basically, is synchronous GenServer.call/3 fast enough so that using Tasks for many calls is unnecessary? Also, unrelated to the main topic, is it okay for Node A to do the “timekeeping”? In this system Node A creates all new events through a rest api. Every other node (Node B included) processes these events.
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
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
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
tty
There is no guarantees on message arrival orders over the network. This is totally outside Elixir/Erlang/Scala/Go/C/Java/etc domain. A flaky router in the network can delay messages while another message which avoids this router arrive timely.
The GenServer.call/3 is as fast as the GenServer.call/3. If the
it would be impossible for the GenServer.call/3 to be fast
All the GenServer.call/3 means is the callee and GenServer process would block until it receives a result.
a. Requests ordering
b. Processing ordering
c. Result ordering
These are independent, it is possible to require processing ordering but not request and result ordering. Are you certain you require this ordering to begin with.
NobbZ
Messages between Node A process 1 and Node B process 2 arrive in order, but might be randomly interleaved by messages of any other process of Node A or Node C (which I suppose to exist, since only 2 nodes don’t make a “star topology”).
But even if order of messages between processes is guaranteed, try as best as you can to remove your dependency on the message.
Often we want ordering where its not actually necessary, and to be honest, the business people which required me to deliver messages in order, didn’t even realize, that I did not. And all I do is holding back cancel messages until I’ve seen the message that gets canceled
joefractal
Several factors which make a definitive answer impossible.
If you are worried about the context switch & overhead of many genserver calls, you can send chunks or even the whole payload.
NobbZ
Well, in general, I do understand this as “how much overhead does
GenServer.call/3add?”, and I tend to say, usually it adds less overhead than implementing something from scratch to push data from one node to the other.Available Bandwith to send the data, CPU time to process the data and sending the reply needs to happen anyway, regardless of a
GenServeris used or something else.