[Spread-users] mbox corruption and timeouts in membership.c

John Schultz jschultz at spreadconcepts.com
Fri Nov 3 12:53:06 EST 2006

-8 (Connection Closed) errors for a client are almost invariably traced to 
a lack of flow control amongst sending applications.  In a multicast 
environment it is very easy for aggressive senders to overrun receivers' 
buffers.  Spread tries not to allow slow readers to exhaust its memory and 
cause the daemon to crash so it disconnects readers that aren't keeping up 
with their flow of traffic.

One recommendation I can give is to turn on the SESSION logging flag and 
then search the log for "sess_kill" and see why it is disconencting your 

I can't think of any timeouts offhand that should cause problems with 
client connections.

John Schultz
Spread Concepts
Phn: 443 838 2200

On Fri, 3 Nov 2006, Matt Garman wrote:

> Hello,
> We are seeing a fair amount of mbox corruption in some of our
> spread-based receiver applications.  This happens more often with our
> Perl-based spread apps.  I.e., what we are finding is that that many
> Spread::receive() calls result in -8 and/or -18 codes.
> The second question, and this may be related to our first problem: we
> are using significantly smaller *_timeout values in our version of
> spread (on the order of 2000--10000 usec).  We believe that the mbox
> corruption may result from one (or more) of these values being too
> small.
> Does anyone have any detailed documentation on these timeout
> parameters (other than the code, obviously :)  Or perhaps general
> guidelines given network topology?  Or is trial-and-error the best
> approach here?
> Thank you,
> Matt
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users

More information about the Spread-users mailing list