I found where the 7s ping/net_connect delay I was seeing if I was
pinging (or multi_call'ing) a node who's connection had timeout comes
from (see net_kernel excerpt below).
I'm glad it's configurable (thanks for the foresight, whoever did
it!), however I need it smaller than 1s, which is the current minimum
I can set.
Is there any chance that in the next release of the net_kernel
we could add a new (equally undocumented, i.e. unsupported) switch:
net_setuptime_millis? I suggest the net_setuptime switch dominates if
present to maintain backwards compatibly.
Funny enough, when the node in question (say c) never started
in the first place, then a multi_call to [a,b,c] does not suffer from
the connection setup delay, it's only because a connection (that timed
out) had been setup initially that I see the kernel setuptime
timeout/delay.
Perhaps someone could educate me here - it seems that perhaps not all
the data structures associated with the timed out connection are
cleaned up (i.e. behavior is different from when the connection has
never been created in the first place).
Thanks,
- Reto
PS: in the meantime, I'll resort to removing the failed node
from the nodeset I multicall to, and then re-add it using a multicast
based discovery protocol (the latter I have anyway). It would be nice
if my app could be naive about all that and just blindly multi_call to
a node set.
--------- net_kernel: ---------
[...]
%% Default connection setup timeout in milliseconds.
%% This timeout is set for every distributed action during
%% the connection setup.
-define(SETUPTIME, 7000).
[...]
connecttime() ->
case application:get_env(kernel, net_setuptime) of
{ok, Time} when integer(Time), Time > 0, Time << 120 ->
Time * 1000;
_ ->
?SETUPTIME
end.
[...]
--------- net_kernel: ---------
______________________
An engineer can do for a dime what any fool can do for a dollar.
-- unknown