[Spread-users] Is there a limit on total traffic sent by Spread?

[Guido van Rossum]

[me]
> > Also, this *is* a multithreaded app; there's one thread receiving and
> > one thread sending.  But the receiving thread is mostly idle: there
> > isn't any traffic going in that direction.

[Tim]
> Absolutely none.  The mailbox receive call is guarded by a select
> with a 1-second timeout, and we don't even try to do an mbox receive
> unless the select says its descriptor is ready for reading.  But it
> should never be ready for reading.

Note that when the other end of a socket is closed, select also says
that the file descriptor is ready for reading!  This is so that you
can call recv() and get the error.  I believe this is exactly what
happened here.  The question is, why is the socket closed?  From the
log message it appears that the Spread daemon fails to read a complete
message and then closes the socket; this would explain why the reading
thread in the client sees an error.

> From looking at the code in Sess_read() in session.c, I think that the
recv() calls here are made while the socket is in non-blocking mode.
Shouldn't we *expect* that the recv() might fail if there is no data
immediately available?  Why does Spread treat this as a fatal (for
this mbox) error?

Are we perhaps sending messages that are too large?  Our payload is
102400 bytes (100K, for some definition of "K" :-).

> > Yet, it *appears* that it gets the error first (before the sending
> > thread gets the same error).
> 
> I can only guess this is a membership message generated by Spread,
> since our app isn't sending anything to any group this mbox has
> joined.  It may be the self-leave message!

I don't think so.  See above.

--Guido van Rossum (home page: http://www.python.org/~guido/)