[Spread-users] More Performance Issues/Questions

[Mike Perik]

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:
> 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
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users