[erlang-questions] Where the Erlang node tick response will get stored ?.

[Ulf Wiger]

The tick message is received in dist_util:con_loop/2:

https://github.com/erlang/otp/blob/master/lib/kernel/src/dist_util.erl#L486

There is a con_loop for each 1:1 node connection, and the tick state simply
keeps track of the number of tick intervals for which no data has been
received on the connection (note that at least ticks should have been
received.)

Based on experience, with such a short ticktime, you might want to pay
attention to the +zdbbl setting for erl (dist_buf_busy_limit). If it is set
too low, there is a risk that the ticker process is suspended and the
connection times out. I believe this is less of a problem than it used to
be, when the distribution buffer busy limit was much lower (and not
configurable.)

BR,
Ulf W

2017-06-06 7:15 GMT+01:00 lankeanandrao <lankeanandrao@REDACTED>:

> Hi all,
>
>      I am running my application in a distributed way, with one server
> node and multiple client nodes and all nodes are started in visible mode.
> Here I want to know when all the client nodes are connected to the server
> node, the client nodes will send the tick message to server node and as
> same as the server will send tick message to all client nodes, here all the
> client nodes send tick response to the server node. So here my question is
>
>    1. Where the tick response came from multiple client nodes is getting
> stored?
>
>    2. If it is getting stored in kernel buffer, what is the buffer size
> and how to find that?
>
>    3. How the tick response's of multiple nodes is getting served by the
> Erlang kernel?
>
> Note: The net tick time is set to 5 Second in all the nodes.
>
> Thanks & Regards,
> Anand Rao L
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170606/b1d661e5/attachment.htm>