<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<p>John Schultz wrote:
<blockquote TYPE=CITE>Could it be that Spread sometimes detects that you
have left (broken
<br>pipe) before it actually sends your msgs out to the other daemons and
<br>therefore discards your msgs? This would explain all of the symptoms.
On
<br>what kind of system are you running? On what kind of system is the
<br>daemon running? What kind of communication are you using to the daemon
<br>(TCP/IP remote or UNIX domain socket to local)?</blockquote>
<p><br><font color="#3333FF">We've experienced this in several different
configuration including:</font><font color="#3333FF"></font>
<p><font color="#3333FF"> - single daemon on Linux w/clients
presumably using domain sockets (whatever the standard test clients use)</font>
<br><font color="#3333FF"> - single daemon on Linux w/remote
client from either same Linux box, different Linux box, or Windows XP</font>
<br><font color="#3333FF"> - two daemons on different Linux
boxes each with local client</font>
<blockquote TYPE=CITE>
<p>BTW, Spread discarding your msgs like this, though not desirable, is
<br>allowed by the safety and liveness properties of the system. To gurantee
<br>that all of your messages are actually sent in the system, the sender
<br>must stay in the group until it receives back its own messages. You
can
<br>do this by making your flooder both a sender and a receiver.</blockquote>
<font color="#3333FF">I'm not sure I understand what you're saying. In
spread, a sender need not even</font>
<br><font color="#3333FF">be a group member to multicast to it, so why
would the sender be required to</font>
<br><font color="#3333FF">stay in the group if it happened to be a member
for a delivery guarantee? Also,</font>
<br><font color="#3333FF">the default flooder is both a sender a receiver
and that is exactly when the problem</font>
<br><font color="#3333FF">occurs. It has not occurred when I use the -wo
write-only flag. I would assume</font>
<br><font color="#3333FF">(naively perhaps) that if SP_multicast returns
with no error, the daemon should</font>
<br><font color="#3333FF">have the message and deliver it no matter what
then happens to the sender.</font>
<blockquote TYPE=CITE> </blockquote>
<blockquote TYPE=CITE>
<p>John
<p>Kelvin Fedrick wrote:
<p>> I just tried it and it doesn't seem to help.
<br>>
<br>> ./spflooder -m 500 send 500 messages with a sequence number and the
spuser
<br>> only received message 1 - 498. The number of messages received is
variable;
<br>> occassionally it gets them all but there are usually a few missing
(e.g.
<br>> 4994 of 5000
<br>> were received on a run I just made).
<br>>
<br>> Kelvin
<br>>
<br>>
<br>> Joshua Goodall wrote:
<br>>
<br>> On Thu, May 08, 2003 at 02:44:37PM -0600,
Kelvin Fedrick wrote:
<br>> > I saw a few previous post on this
from July 2002, but I never saw a
<br>> > definitive resolutions. We've experienced
the same problem. We
<br>> > modified the spflooder to send a
message sequence number and find
<br>> > that often a small percentage of
messages at the end are never
<br>> delivered
<br>> >
<br>> > (e.g. 400 sent but only 398 delivered).
<br>> > Placing a 1 second sleep at the end
of the flooder program
<br>> main(), just
<br>> > before exit seems to fix this. Also
I haven't been able to
<br>> reproduce it
<br>> > so
<br>> > far running spflooder as write-only.
Any ideas?
<br>>
<br>> Instead of a sleep, does adding a SP_disconnect(Mbox)
also fix it
<br>> for you?
<br>>
<br>> J
<br>>
<br>> --
<br>> Joshua Goodall
"tea makes itself"
<br>> joshua@roughtrade.net
- Ana Susanj
<br>>
<p>_______________________________________________
<br>Spread-users mailing list
<br>Spread-users@lists.spread.org
<br><a href="http://lists.spread.org/mailman/listinfo/spread-users">http://lists.spread.org/mailman/listinfo/spread-users</a></blockquote>
</html>