The problem I am talking about occurs while the network is in partitioned condition. When the network connection is re-established and the Erlang node is connected with a net_adm:ping/1 the message queue drains out quickly and the nodes start working normal.<br>
<br>As I said before, this delay occurs only after an abnormal network disconnection. If the receiving Erlang node is shutdown gracefully, the message delay doesn't occur.<br><br>I doubt, this occurs only when the packets sent out are going to a black-hole and nobody responds that the destination TCP entity is unavailable.<br>
<br>- Eranga<br><br><br><br><div class="gmail_quote">On Wed, Mar 5, 2008 at 12:21 AM, Scott Lystig Fritchie <<a href="mailto:fritchie@snookles.com">fritchie@snookles.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;">
Hi, everyone.  I've read forward in the thread ... and am wondering if<br>
there's a simpler cause?  Since the default distribution mechanism rides<br>
on top of TCP, the delay might be caused by TCP's exponential back-off<br>
when packet loss is encountered?  A quick packet capture could verify<br>
this theory: there would be a big delay after the network partition is<br>
fixed (i.e. plug cable back in, "ifconfig {IFACE} up", whatever) and<br>
before the next packet (in either direction) is transmitted.<br>
<font color="#888888"><br>
-Scott<br>
</font></blockquote></div><br>