<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
>From reading past mailings I will try to recap what my understanding is:<br>
<br>
Basically, if the token goes around the ring several times and nothing
is sent, then the leader (it doesn't matter who it is for the purpose
of the implementation), will hold onto the token for hurry_timeout to
stop the token from being past for no reason.&nbsp; All other daemons also
know that the leader is holding it because they have calculated the
exact same 0-traffic situation.&nbsp; If any of them need to send data, they
are supposed to be able to request the "holding" stop.&nbsp; Only if no one
does this, then hurry_timeout will occur, and the token pass around as
normal (possibly being held again).&nbsp; <br>
<br>
It does appear from people that there may be a bug in requesting the
leader to release the token before the timeout occurs when others have
data to send.&nbsp; Although I have no basis to state this myself, and never
looked at the code :)<br>
<br>
You can change the hurry_timeout to something much less, just realize
that you'll be sending the token that much more often, 24/7 around the
clock.&nbsp; Its design was simply to save bandwidth when no one was doing
anything.&nbsp; Under heavy or continuous load this would not occur.<br>
<br>
One posting questioned if possibly the code to request the token during
this holding period wasn't working properly, but there didn't seem to
be any response to it, or further investigation.&nbsp; <br>
<br>
In any event, changing the hurry_timeout to an acceptable delay, will
solve your problem, and remember its only when the load is non-existant
for several trips around the ring (which given can occur probably
within fractions of a second of idling) if on a LAN.<br>
<br>
--paul<br>
<br>
<br>
Mike Perik wrote:
<blockquote cite="mid200412220952.44353.mikep@foxriver.com" type="cite">
  <pre wrap="">Shouldn't the leader give up the token before going into the select?

What's the purpose of the leader?

Is this a bug or just a side effect of the implementation?

Seems to me that this should be documented especially for situations where you 
have 1 talker and many listeners.  The leader needs to the be talker.  
Couldn't there be some kind of agreement made in the ring that whoever is 
talking a lot becomes the leader?  Or the leader could determine that someone 
else out there is doing the talking and I'm not so I'll give up the token a 
little quicker.

Thanks,
Mike

On Tuesday 21 December 2004 01:27 pm, Mike Perik wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Ok,  I think I've found the problem.

In the spread.conf I had two machines.  The leader is always the first
machine.  The leader is the one who holds onto the token and he'll hold
onto the token for the Hurry_timeout.   Since the first machine in the
configuration file is the client machine he holds onto it for Hurry_timeout
seconds.  It goes into a select with the Hurry_timeout and since the
server/publisher is waiting for the token to publish the client waits the
whole time (Hurry_timeout or 2 seconds by default) since there is nothing
to read.  I'm assuming the server queues  up all the messages that are
being sent and when it gets the token it sends them all.

I switched the order of the two machines in the configuration file around
and the problem essentially went away.

If I'm correct on how this is working, I have a couple of questions?

What if I have two servers that are publishing data at a high rate and
neither of them are the "leader"?
What kind of delay is this going to cause?
If I have 20-30 spread daemons in my segment how much additional latency is
there going to be?

I believe this is why the spmonitor shows the "last" which was the server
having a high number of retransmits.

Is this a known issue?

How would I best design my system around this problem?

Thanks,
Mike

_______________________________________________
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>
  <pre wrap=""><!---->
_______________________________________________
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>
</body>
</html>