BBQPupper
How fast is GenServer.call/3?
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.
Most Liked
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
GenServer.call, do: very_slow_function() end
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.
- Given you expect some ordering there are 3 possible distinct ordering:
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.
- In general Node A can do the “timekeeping” because it is the entry point into your system. It is possible that Node B is the actual entry point but that is something you have to decide, partially by your answer to (3).
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 
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
The deployment platform built for Elixir: PaaS ease, VPS control.
Categories:
Sub Categories:
Forums
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.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"