CODEWITHSUNDEEP
erlangelixirerlang-otpgen-server
Charlie
Charlie

Reputation: 4329

Can I call GenServer client functions from a remote node?

I have a GenServer on a remote node with both implementation and client functions in the module. Can I use the GenServer client functions remotely somehow?

Using GenServer.call({RemoteProcessName, :"app@remoteNode"}, :get) works a I expect it to, but is cumbersome.

If I want clean this up am I right in thinking that I'd have to write the client functions on the calling (client) node?

Upvotes: 1

Views: 2148

Answers (3)

zxq9
zxq9

Reputation: 13154

TL;DR

Yes

Discussion

There are PIDs, messages, monitors and links. Nothing more, nothing less. That is your universe. (Unless you get into some rather esoteric aspects of the runtime implementation -- but at the abstraction level represented by EVM languages the previously stated elements (should) constitute your universe.)

Within an Erlang environment (whether local or distributed in a mesh) any PID can send a message addressed to any other PID (no middle-man required), as well as establish monitors and so on.

gen_server:cast sends a gen_server packaged message (so it will arrive in the form handle_cast/2 will be called on). gen_server:call/2 establishes a monitor and a timeout for receiving a labeled reply. Simply doing PID ! SomeMessage does essentially the same thing as gen_server:cast (sends a message) without any of the gen_server machinery behind it (messier to abstract as an interface).

That's all there is to it.

With this in mind, of course you can use gen_server:call/2 across nodes, as long as they are connected into a cluster/mesh via disterl. Two disconnected nodes would have to communicate a different way (network sockets) and wouldn't have any knowledge of each other's internal mapping of PIDs, but as long as disterl is being used they all translate PIDs amongst themselves quite readily. Named processes is where things get a little tricky, but that is the purpose of the global module and utilities such as gproc (though dependence on such facilities beyond a certain point is usually an indication of an architectural problem).

Of course, just because PIDs from any node can communicate with PIDs from another node doesn't always means they should. The physical topology of the network (bandwidth, latency, jitter) comes into play when you start sending high-frequency or large messages (lots of gen_server:calls), and you have always got to think of partition tolerance -- but for off-loading heavy sorts of work (rare) or physically partitioning sub-systems within a very large system (more common) directly sending messages is a very simple way to take a program coded for a single node and distribute it across a cluster.

(With all that in mind, it is somewhat rare to see the rpc module used.)

Upvotes: 2

Pouriya
Pouriya

Reputation: 1626

For large number of calls, It's better to user gen_server:call/2-3.
If you want to use rpc:call/4-5, you should know that it is just one process named rex on each node for handling all requests. So if it is running one Mod:Func(Arg1, Arg2, Argn), It can not response to other request at this time !

Upvotes: 3

Justin Wood
Justin Wood

Reputation: 10061

You can use the :rpc.call/{4,5} functions.

:rpc.call(:"app@remoteNode", MyModule, :some_func, [arg1, arg2])

Upvotes: 4

Related Questions