[rabbitmq-discuss] getting started, broker runs; can't get status

[Dmitriy Samovskiy]

Matthias Radestock wrote:
> Dmitriy,
> 
> Dmitriy Samovskiy wrote:
>> Like Matthias said above, it's got to be something that prevents epmd 
>> communications with nodes.
> 
> Right, but curiously it doesn't prevent epmd communication completely, 
> i.e. the node registration traffic goes through but the query traffic 
> doesn't.
Yep, the way I am reading this, ALIVE_REQ is alone on its connection, other commands use 
their own connections. So looks like the second connection always fails (and I assume 
ALIVE_REQ will always be the first one)?

http://github.com/mfoemmel/erlang-otp/blob/c6341282a575b4cdaa64c6f7013f9eab05fe0cf4/erts/epmd/src/epmd_srv.c


* In all but one case there is only one request for each connection made
* to this server so we can safely close the socket after sending the
* reply. The exception is ALIVE_REQ where we keep the connection
* open without sending any data. When we receive a "close" this is
* an indication that the Erlang node was terminated. The termination
* may have been "normal" or caused by a crash. The operating system
* ensure that the connection is closed either way.

* Incomplete packets are thrown away after a timout. The Erlang node
* doing the request is responsible for completing in it in a reasonable time.
*
* Note that if the server gets busy it may not have time to
* process all requests for connection. The "accept()" function
* will on most operating systems silently refuse to accept more
* than 5 outstanding requests. It is the client's responsibility
* to retry the request a number of times with random time interval.
* The "-debug" flag will insert a delay so you can test this
* behaviour.
*
* FIXME: In this code we assume that the packets we send on each
* socket is so small that a "write()" never block
*
* FIXME: We never restarts a read or write that was terminated
* by an interrupt. Do we need to?