gen_server:call internal format & OTP compatibility

[Roberto Ostinelli]

This makes sense, Rickard. Thank you for your clarification for what the ±
2 releases of distribution also covers the infra-node message protocols.

Best,
r.

On Thu, Oct 14, 2021 at 4:23 PM Rickard Green <rickard@REDACTED> wrote:

>
>
> On Wed, Oct 13, 2021 at 10:56 PM Roberto Ostinelli <ostinelli@REDACTED>
> wrote:
>
>> All,
>> I'm writing a distributed library that I would like to be compatible with
>> clusters running multiple OTP versions. I am aware that backwards
>> compatibility for the distribution protocol is only promised for two major
>> releases in either direction, but that's already pretty significant.
>>
>> Therefore, for instance maybe I should avoid using gen_server:call/2,3 to
>> call processes running on a different node with something like
>> gen_server:call({?MODULE, RemoteNode}, Message).
>>
>> My thinking is that the internal call message format of gen_server is an
>> internal implementation detail subject to change, thus it might be
>> incompatible on different OTP versions, and if this is the case then the
>> previous call would fail.
>>
>>
> However, it's a pity to not use the robust usage of standard API calls. On
>> the other hand, it does not look like this message format has changed
>> recently, so maybe I'm just overthinking it and should just use
>> gen_server:call/2,3 without fear of breaking anything.
>>
>> I'd like to hear some thoughts, if someone would like to chime in.
>>
>> Thanks,
>> r.
>>
>
> We don't make changes in the gen_server protocol which will cause failures
> to communicate with OTP nodes of +-2 releases. Communicating with nodes +-3
> releases might fail. This is also the case if you implement your own
> protocol if it utilize the Erlang distribution. That is, I see no point in
> implementing your own protocol unless you also stop using the Erlang
> distribution all together. It is not safe to connect Erlang nodes over the
> Erlang distribution that differs more than 2 releases. Safe in the sense
> that you might get communication failures in other subsystems even though
> your protocol might work.
>
> Regards,
> Rickard
> --
> Rickard Green, Erlang/OTP, Ericsson AB
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20211014/35d31d06/attachment.htm>