Thanks for the info and it makes sense.<br><br>In "busy port" situation, do queued messages get discarded if the queue grows beyond a max? Is it FIFO or LIFO? Is there a way to configure this message queue size? Can one inet_drv "busy port" block all other connected (live) node communication?<br>
<br>As I said before the net_adm:ping/1 returns "pang" immediately. Then why doesn't the message delivery function identify that the remote node is inaccessible, hence return immediately with an error? <br><br>
How the message delivery method implemented in Erlang? Is it to return as soon as the message is handed over to the local inet_drv or delivered to the receiving Erlang node's inet_drv and after receiving a confirmation or something?<br>
<br>- Eranga<br><br><br><br><div class="gmail_quote">On Tue, Mar 4, 2008 at 10:28 PM, Kenneth Lundin <<a href="mailto:kenneth.lundin@gmail.com">kenneth.lundin@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
When connectivity is broken abnormally the sending node will detect<br>
this within 45-60 seconds as default. This can be changed with the<br>
net_tick_time environment variable in application kernel.<br>
Before the detection the sending node will try to send the message and<br>
if not possible it will be queued in the inet-driver. If the queue<br>
gets bigger than a certain max a so called "busy port" will occur<br>
which will block the sending Erlang process.<br>
This occurs when the receiving side of the distribution socket does<br>
not read what is<br>
sent to it which is the case when you have no connectivity.<br>
<br>
another scenario is that the receiving node is detected as down and<br>
an auto connect (including handshake) is performed for the first<br>
message sent after<br>
the broken connection. This will take in the order of 10 seconds before timeout.<br>
<br>
If you want to avoid this for a very crucial process (i.e avoid<br>
blocking of that particular Erlang process) you can send the message<br>
with erlang:send_nosuspend/2 or 3. Warning! these functions should be<br>
used with extreme care, Read the manual!<br>
<br>
Note that this has nothing to do with HiPE (i.e native code).<br>
An abnormal termination of the connectivity for example by unplugging<br>
the network cable will have this effect.<br>
<br>
/Kenneth Erlang/OTP team Ericsson<br>
<div><div></div><div class="Wj3C7c"><br>
On 3/4/08, Eranga Udesh <<a href="mailto:eranga.erl@gmail.com">eranga.erl@gmail.com</a>> wrote:<br>
> The problem occurs when the network connectivity is broken (abnormally). The<br>
> receiving node is not receiving messages. The sending  processes are<br>
> blocked, since those message delivery calls (gen_event:notify/s, etc) are<br>
> waiting for about 10 secs to return. We checked the implementation of such<br>
> calls and notice, the functions are waiting until the messages are delivered<br>
> to the receiving node. Is there's a way (a system flag may be) to avoid such<br>
> blocking and to return immediately?<br>
><br>
> BRgds,<br>
> - Eranga<br>
><br>
><br>
><br>
><br>
> On Mon, Mar 3, 2008 at 6:51 PM, Chandru<br>
> <<a href="mailto:chandrashekhar.mullaparthi@gmail.com">chandrashekhar.mullaparthi@gmail.com</a>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On 03/03/2008, Eranga Udesh <<a href="mailto:eranga.erl@gmail.com">eranga.erl@gmail.com</a>> wrote:<br>
> > > Hi,<br>
> > ><br>
> > > I am experiencing a high message passing delay between 2 Erlang nodes,<br>
> after<br>
> > > an abnormal network disconnection. Those 2 nodes are in a WAN and there<br>
> are<br>
> > > multiple Hubs, Switches, Routes, etc., in between them. If the message<br>
> > > receiving Erlang node stopped gracefully, the delay doesn't arise. Doing<br>
> > > net_adm:ping/1 to that node results no delay "pang". However<br>
> > > gen_event:notify/2, gen_server:cast/2, etc. are waiting for about 10<br>
> seconds<br>
> > > to return.<br>
> > ><br>
> > > What's the issue and how this can be avoided?<br>
> ><br>
> > Have you tried putting a snoop to see whether the delay is on the<br>
> > sending/receiving side?<br>
> ><br>
> > This might be useful:<br>
> <a href="http://www.erlang.org/contrib/erlsnoop-1.0.tgz" target="_blank">http://www.erlang.org/contrib/erlsnoop-1.0.tgz</a><br>
> ><br>
> > cheers<br>
> > Chandru<br>
> ><br>
><br>
><br>
</div></div><div><div></div><div class="Wj3C7c">> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
</div></div></blockquote></div><br>