Hello, An ven., déc 18, 2009, Bogdan-Andrei Iancu schrieb: >[email protected] wrote: >>>> You may try to increase the number of tries to something higher - >>>> 3200, just to see if that is the problem: >>>> >>>> see tls/tls_server.c , line 689 >>>> #define MAX_SSL_RETRIES 320 >>>> >>> This doesn't make sense to me. If 320 retries are attempted with no >>> write op success, then trying 3200 can't be the solution. Rather, it >>> must be that I have an error in the config script or some permission >>> problem no? >>> >> Sadly, the only thing I could do to solve the problem was to >> increase 320 as Bogdan suggested. I raised it to 3200, but >> surely there is a lower 'cieling' that would work. It leaves >> me with a somewhat sick feeling however, because this seems >> very hacky and probably only masks the symptom and leaves >> the real problem intact (which could surface again in some >> other form.) >> >It is not really a hack :) .... i tend to think this number vary from OS >to OS, from server to server .....like how slow the write ops take place >- on some system is faster, on other is not..... > By the way, even when MAX_SSL_RETRIES is set to almost infinity, the same errors reappear when lowering the number of child processes. This could be a clue for whoever decides to look into this bug.
In the current state of development, it seems the workaround is: Increase MAX_SSL_RETRIES to almost infinity Increase tcp_children to the number of UACs (not scalable) Log how many SSL retries are really needed until success Lower MAX_SSL_RETRIES from almost infinity to what is needed Does that sound right? Is this acceptable as far as scalability goes? _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
