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

[Herbert Rubens]

The Sess_read() method in session.c is registered to be called by the
event system upon activity on a file descriptor.  The event system is
using select to determine whether there is at least 1 byte available to
be read or that an error has occurred.  Since the socket is non-blocking
and it is in a select() call, it should never return EWOULDBLOCK.  

The only that thing I noticed that looked strange was that the ioctl()
call is not ifdef'd for ARCH_PC_WIN95 since I believe the windows
version is called ioctlsocket() and the ioctl_cmd on windows I believe
is an unsigned long and not an int like on unix platforms.


-Herb



-----Original Message-----
From: spread-users-admin at lists.spread.org
[mailto:spread-users-admin at lists.spread.org] On Behalf Of Tim Peters
Sent: Saturday, January 19, 2002 11:06 PM
To: spread-users at lists.spread.org
Subject: RE: [Spread-users] Is there a limit on total traffic sent by
Spread?

]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.



_______________________________________________
Spread-users mailing list
Spread-users at lists.spread.org
http://lists.spread.org/mailman/listinfo/spread-users