On Wed, 2010-02-17 at 17:06 -0700, hj lee wrote: > > > On Wed, Feb 17, 2010 at 4:42 PM, Steven Dake <[email protected]> wrote: > > On Wed, 2010-02-17 at 16:40 -0700, hj lee wrote: > > > > Actually I changed the code to use TCP just for sending a > token, it is > > working very well. "very well" means I do not see token > timeout any > > more. I know this is an ugly hack! The main reason I want to > use TCP > > is I am seeing token lost timeout in heavy load, so the > cluster is > > divided for very short time, which caused some problem in my > > application. If I run the system over night, I usually see > one or two > > token lost timeout. the easy fix will be increase token > timeout, but I > > have a strict requirement on timeout, so I couldn't increase > it. So I > > tried to use TCP. After adding TCP transport just for token > transmit, > > this timeout does not happen any more. > > > > The token is transmitted by unicast, so this chagne will > work with > > more than two nodes. And I think there will be cases or > environment > > this TCP token transmit may be useful or work better. At > least it > > solves my case. > > > > Thanks > > hj > > > > > > > Did you try increasing (from man page): > token_retransmits_before_loss_const > This value identifies how many token > retransmits > should be > attempted before forming a new configuration. > If this > value is > set, retransmit and hold will be automatically > calculated > from > retransmits_before_loss and token. > > The default is 4 retransmissions. > > > Yes, I tried it. I understand these config parameters very well now. > But our token lost timeout is very short! So there is not much room to > play with other parameters. The UDP is just thrown away in heavy > traffic! > > Thank very much > hj >
What is your token lost timeout period? Have a patch for your tcp token sending for me to look at? Regards -steve _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
