> > OK I see.. yes there are probably things slowing down radiator.. we have > two queries to mysql databases and one towards pam(using Kerberos) and > I'm guessing all this makes the whole process pretty slow.. especially when > they are under load. > > > > I guess there are no way to make the externals wait longer for a response ? > > The RetryTimeout parameter in AuthBy RADIUS controls this. If you add a > second, it may help. Note that there are two kinds of duplicates: ones > that are ignored and ones that cause resending of the reply. The log > message 'retransmit reply' or 'ignored' depending on if the reply was > already sent or not. The idea here is to ignore the duplicate request if > the original request is still being processed. > > If the reply is retransmitted, then the original reply may have gotten > lost or the requests in the incoming socket queue are processed too slow > which might be your case. If the queue is not emptied quickly enough, > the external may think think the request it sent (or the corresponding > reply) may have been lost.
I see.. I have a cause for the duplicates I think. It seems like the configuration I'm using is never sending a reject back to the "external" proxys and I'm guessing that causes them to try again until they timeout the request ? It seems like if I add a Authby internal with a default reply of reject this causes most of my duplicates to vanish.. I'm using a AuthBy Group that has ContinueUntilAccept set and even when a user gets rejected it simply continues.. which would be the natural thing with ContinueUntilAccept but this also causes the rejected login to become "ignored" in the end.. So an internal authby with default reject should remedy this I guess.. Thanks, Patrik Forsberg _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
