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

[Tim Peters]

]Guido van Rossum]
> 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?

This sure looks like a bug to me:  AFAIK, while it's common under light load
for a non-blocking recv() to return all the data you're expecting, it's also
possible that no data at all may yet be available, and then a -1 return
coupled with errno = EAGAIN or EWOULDBLOCK (or WSAGetLastError() =
WSAEWOULDBLOCK on Windows) is normal behavior.  Also possible that only some
of the data expected is immediately available.  So I don't understand either
why the session here is killed if no data happens to be available -- or why
the function returns normally if at least one byte but not all of the
expected data happens to be available.

Since we've died this death more than once in a spot where the app sends
100K Spread messages at a prodigious rate, and the problem went away after
you put a short sleep after each multicast, the notion that recv() simply
gets starved for a little while under heavy load fits the symptoms and the
workaround too.