[Spread-users] Gaps between message send
jschultz at spreadconcepts.com
Tue Nov 16 15:04:10 EST 2010
The Token_timeout defines how long a daemon will wait without receiving the token before it declares its ring dead.
The Hurry_timeout defines how quickly the token will be regenerated by the ring leader if the token doesn't seem to be circulating.
The other membership.c timeouts define how the various portions of the membership algorithm work.
The token is sent by a daemon immediately after it sends any messages it has to send.
You are probably experiencing significant loss which is causing the token to be lost. In such a case, the system will wait until the Hurry_timeout fires and then the token will be sent from the leader again. You can try lowering that timeout and see what happens. However, you want the Hurry_timeout to be significantly longer than the actual time it takes for your token to circulate around the ring you have defined or you will generate pointless token overhead.
The best solution is to figure out why you experiencing such loss (assuming my hunch is correct). You can run spmonitor and look at the status of all your daemons and if you see the "retrans" field numbers increasing much at all, then loss is very likely your problem.
John Lane Schultz
Spread Concepts LLC
Phn: 301 830 8100
Cell: 443 838 2200
On Nov 16, 2010, at 2:41 PM, Heimo Zeilinger wrote:
Thanks for your help regarding my last issues! However, time goes by and new issues rise – that’s life.
Currently I am working on sending periodically transactions to a database using 2 daemon processes. When I tested the setup the first time I recognized that these messages are sent in blocks with a gap of around 12 seconds in between. As this gap occurs rather periodically I am sure that the token timing parameters are the reason for it even though I have not been able to find the correct settings, yet. I reduced the parameters in membership.c to a third and decreased the gap to 8 seconds. However, this is still quiet unsatisfying for my application. By the way, the CPU load is around 4 -6%. Two question raised for me:
1. I interpret the token timers as they define the MAXIMUM time a daemon process will wait for the token. Is this correct, or do they define the time that a daemon process holds it no matter if it has already finished it tasks or not. Currently the daemon process seams to send a block of messages and afterwards it is doing more or less nothing for around 11 seconds.
2. Is it possible to configure the daemon the way that it passes on the token to the next daemon process in the moment that it finished its task?
Actually I use total ordering, even though a different configuration does not take any effect.
Maybe you know an answer to the problem!
Spread-users mailing list
Spread-users at lists.spread.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3805 bytes
Desc: not available
Url : http://lists.spread.org/pipermail/spread-users/attachments/20101116/65112bbe/attachment.bin
More information about the Spread-users