<div><br></div><div>John,</div><div><br></div><div>We have encountered the errors where spread disconnects consumers that are not fast enough.  We have written a fair amount of code to handle this error (including flow control) and recover gracefully.  In this particular instance the client is only a producing content to be sent on spread and is not consuming any messages.  It does not join a group and does not consume any messages.  Does spread ever disconnect a producer for being too bursty? </div>
<div><br></div><div>Your discussion on flow control is quite good and has several concepts that we have implemented.</div><div><br></div><div>We are surprised to see a producer being disconnected from spread.  The spread daemon and clients are all running locally (localhost) so the socket connection should only be terminated by an internal process.</div>
<div><br></div><div>Thanks in advance,</div><div>##Shawn</div><br><br><div class="gmail_quote">On Mon, Nov 5, 2012 at 1:16 PM, John Schultz <span dir="ltr">&lt;<a href="mailto:jschultz@spreadconcepts.com" target="_blank">jschultz@spreadconcepts.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A TCP connection reset error typically indicates that the other end of the peer connection has already been closed.  In your case, the Spread daemon has likely already closed the client connection on which you are trying to send.<br>

<br>
In Spread, this happens most often when a client isn&#39;t reading fast enough from the Server.  After a while, the message delivery queue on the daemon for that client gets too large and it kills the client connection for using too much of its memory resources.<br>

<br>
This typically indicates that your sending applications are either (a) too bursty, (b) persistently too fast in how they send to the group or your receivers are (c) occasionally too slow / unresponsive.  The fact that this problem is intermittent hints that the problem is more likely (a) and/or (c).<br>

<br>
To avoid this issue you need to have application level flow control such that your senders can&#39;t overwhelm your receivers (if that is compatible with your application).<br>
<br>
Here&#39;s a primer I wrote on application level flow control a long time ago:<br>
<br>
<a href="http://lists.spread.org/pipermail/spread-users/2002-March/000655.html" target="_blank">http://lists.spread.org/pipermail/spread-users/2002-March/000655.html</a><br>
<br>
Cheers!<br>
<br>
-----<br>
John Lane Schultz<br>
Spread Concepts LLC<br>
Phn: <a href="tel:301%20830%208100" value="+13018308100">301 830 8100</a><br>
Cell: <a href="tel:443%20838%202200" value="+14438382200">443 838 2200</a><br>
<div class="im"><br>
On Nov 5, 2012, at 3:03 PM, Shawn Bradford wrote:<br>
<br>
<br>
Hello,<br>
<br>
We are currently using spread and have found this error occurring quite frequently. Unfortunately there is little information on write() errors to be found on the net (many more read() errors).<br>
<br>
spread.SpreadException: write(): java.net.SocketException: Connection reset<br>
<br>
Would someone be able to describe what would be a potential issue causing this?  I am looking for some guidance as to the source of the error (maybe from a developer) to assist in debugging the error.<br>
<br>
We have tried to write several test apps to replicate the bug but have been unsuccessful.  Our system is quite large with many moving parts and it is unclear as to what sequence of events are causing the errors.<br>
<br>
We are using spread 4.1 on 64 bit centos 5.5.<br>
<br>
Thanks in advance,<br>
##Shawn<br>
<br>
--<br>
</div><div class="im">*         Director Software | Mojix Inc.<br>
  phone : <a href="tel:%2B1.562.221.3474" value="+15622213474">+1.562.221.3474</a><br>
  email : <a href="mailto:shawn.bradford@mojix.com">shawn.bradford@mojix.com</a><br>
  web : <a href="http://www.mojix.com" target="_blank">www.mojix.com</a><br>
<br>
Unless expressly identified to the contrary herein, this email and any attachments contain  and constitute confidential and  proprietary   material  and information for the sole use of the intended recipient. If you are not the intended recipient or otherwise received this e-mail in error, please (i) immediately delete this email and any attachments, print outs and copies of the foregoing and (ii) please notify me immediately by responding to this e-mail message.<br>

<br>
</div>_______________________________________________<br>
Spread-users mailing list<br>
<a href="mailto:Spread-users@lists.spread.org">Spread-users@lists.spread.org</a><br>
<a href="http://lists.spread.org/mailman/listinfo/spread-users" target="_blank">http://lists.spread.org/mailman/listinfo/spread-users</a><br>
<br>
</blockquote></div><br>