<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Gordan Bobic wrote:
<blockquote
 cite="midPine.LNX.4.44.0703281346470.15201-100000@skynet.shatteredsilicon.net"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">You describe reading
succesfully up to a certain point and then always getting a nothing
back.  This is quite a bit more specific than "loosing messages" in
that it seems like you lost the stream.
        </pre>
      </blockquote>
      <pre wrap="">Indeed, but it still strikes me as a pretty poor design. Dropping a  
client
that can't keep up isn't exactly a "reliable" messaging feature. It is
particularly poor that it does this even with UNRELIABLE_MESS  
messages.
Surely, at least those should be dropped when the queue overflows,  
rather
than disconnecting the client?
      </pre>
    </blockquote>
    <pre wrap="">This is spread's design.  Having a slow reading client slow down all  
operations to a crawl isn't usable either.  So, Spread places the  
responsibility of flow control on the user.  It has nothing to do  
with poor design.  Disconnecting slow clients so that other clients  
can continue to operate reliably is intended behaviour, so the design  
meets those intentions quite well..
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Not really. In the case where there is only one reader, dropping that 
reader because the writers are overwhelming it isn't a side-effect I can 
imagine being useful or desirable.
  </pre>
</blockquote>
What is to prevent other subscribers (i.e., "readers") from joining the
group at any time?&nbsp; Are you asking for a Spread configuration option to
essentially provide one-way communication to a single subscriber?<br>
<blockquote
 cite="midPine.LNX.4.44.0703281346470.15201-100000@skynet.shatteredsilicon.net"
 type="cite">
  <pre wrap="">
  </pre>
</blockquote>
<blockquote
 cite="midPine.LNX.4.44.0703281346470.15201-100000@skynet.shatteredsilicon.net"
 type="cite">
  <pre wrap="">
It also means that if there is a single flooder flooding the network 
faster than any of the readers can read, e.g. due to a bug in the sending 
code somewhere, or even just having a sending machine that is so much 
faster than the others that it is generating messages faster than the 
listeners can process them, all the listeners get dropped. By the basic 
rule of concatenation being easier/faster than parsing/splitting, for most 
processes, readers are likely to be at a disadvantage.

  </pre>
</blockquote>
That is why subscribers should only receive/queue messages for
processing elsewhere (perhaps in another thread).&nbsp; My view is that it
is generally less robust to have subscribers performing message
receiving AND message processing.<br>
<blockquote
 cite="midPine.LNX.4.44.0703281346470.15201-100000@skynet.shatteredsilicon.net"
 type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">The perl wrapper around the Spread library is really thin XS.  It
does no interpretive dance :-)  It doesn't much with signals in any
fashion nor does it intentionally hide return values or side effects
of the libspread API calls.
        </pre>
      </blockquote>
      <pre wrap="">Which is all fine, but the fact remains that when you call receive()
without a timeout, any signal traps you set cause the signals to  
disappear completely.
      </pre>
    </blockquote>
    <pre wrap="">Take it up with libspread or perl itself.  The perl wrappers do no  
signal handling or sigset modifications.  Assuming that the libspread  
SP_receive call doesn't suspend signals, then the issue is with  
perl.  FWIW, I have several daemons written in perl that SP_receive  
without a timeout and my SIGHUP handlers appear to work just fine.   
Perhaps something else is interfering?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
It could be a peculiarity of my perl version (standard FC6), but it only 
seems to happen with the Spread library.

Gordan


_______________________________________________
Spread-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Spread-users@lists.spread.org">Spread-users@lists.spread.org</a>
<a class="moz-txt-link-freetext" href="http://lists.spread.org/mailman/listinfo/spread-users">http://lists.spread.org/mailman/listinfo/spread-users</a>
  </pre>
</blockquote>
<br>
</body>
</html>