[Spread-users] Spread Reliability

[Theo Schlossnagle]

On Mar 28, 2007, at 5:11 AM, Gordan Bobic wrote:

> On Tue, 27 Mar 2007, Theo Schlossnagle wrote:
>
>> On Mar 27, 2007, at 12:18 PM, Gordan Bobic wrote:
>>
>>> I figured that was probably the case, due to the way the reception
>>> fails.
>>> I don't suppose there is a different Spread library for Perl?
>>
>> Is it possible the perl Spread client was disconnected from the
>> daemon (due to not reading fast enough)?
>
> It is possible (and in fact quite likely), but I would have  
> expeected an
> obvious error or an exception to be thrown.
>
> Dropping the client (especially silently) that can't keep up  
> strikes me as
> a pretty poor design.

Perl doesn't have exceptions and can't throw them.  It has eval  
blocks and can die from within them.  The spread client library does  
not throw any exceptions, so the perl xs wrapper do not either.   
SP_receive returns undef on error (as is common for the end of a  
stream in perl) and the errors are accessible via $sperrorno and  
$sperror (as mentioned in the very terse docs).

Running a command, not getting the expected result and then having  
the error available to you doesn't seem silent to me -- it's how most  
procedural languages operate.

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

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

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

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?

// Theo Schlossnagle
// Principal at OmniTI: http://omniti.com
// Esoteric Curio: http://www.lethargy.org/~jesus/