[Spread-users] Re:[Fwd: Re: [Spread-users] Spread

Cosimo Calabrese the_tube at libero.it
Thu Feb 6 09:36:22 EST 2003



Cosimo Calabrese wrote:

>Hi,
>
>I'm working with a group communication Java application based on Spread; this application sends messages to Spread, and Spread sends them in multicast to a cluster. 
>
>When I try to send a lot of messages per second, Spread kills the receiving group member after the reception of a certain number of messages. The java application reports this error:
>
>spread.SpreadException: read(): java.net.SocketException: Connection reset
>at spread.SpreadConnection.internal_receive(SpreadConnection.java:1057)
>at spread.SpreadConnection.receive(SpreadConnection.java:1021)
>
>This error doesn't happen when I send messages at a slower rate.
>
>Any hint? I think that Spread kills me when the input buffers are full. How can I resolve this problem? Should I modify any of the #define variables?
>
>Thanks, Cosimo.
>
>
>
>_______________________________________________
>Spread-users mailing list
>Spread-users at lists.spread.org
>http://lists.spread.org/mailman/listinfo/spread-users
>
>  
>
Yes, Spread does disconnect client sessions for not receiving when its 
buffers get full.  To solve this, you could look at extending buffers to 
make it more unlikely that Spread will need to disconnect your client. 
 However, if its really a case of your sender overwhelming the receiver, 
the only solution that will prevent this problem from recurring is 
implementing some flow control.  Probably something simple is all you 
will need.  What is you application like?  What is your Spread 
configuration like?  Someone can try to answer your question more 
specifically with further information.

--Ryan




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



Ok, but I think that a flow control is very hard to implement in my case; how can I extend the Spread buffers instead? 

Thanks, Cosimo.








More information about the Spread-users mailing list