If you enabled keep-alive, then please set the recv_timeout to a lower value.
The recv_timeout value prevents a thread from returning to the pool when keep-alive is used, since the thread will be waiting for more requests over the current connection. Hope this helps. - Robert --- In [email protected], "rusekd" <rus...@...> wrote: > > This is my situation and I have not been able to find a solution within this > list or elsewhere. > > I have a standalone ssl web service running, accepting connections and > farming them out to a pool of threads (of a fixed size). The main thread > accepts the connection, copies the context and calls soap_ssl_accept on the > copy. The copy is placed into a queue and picked-up by the worker threads > which call serve on the objects. > > The problem arises when, in a browser (firefox 3.0), I browse to the web > service's WSDL (?wsdl). If I accept the self-signed certificate, all is well > and I see the WSDL in my browser. However, if I reload the page (thus > initiating a new connection and abandoning the other one) without accepting > the certificate, and if I do this enough times equal to the number of threads > in the pool, the server becomes unresponsive. So, what is happening is that > the pool is busy with all N threads blocking somewhere in the serve method on > the service. This never times out (at least not after a day). > > I am assuming that the SSL handshake does not complete and so the SSL engine > is stuck waiting for something that will never happen?? > > Am I correct? How can I handle this case? The recv_timeout and send_timeout > properties do not seem to help. > > I am running this on Windows XP under visual studio 8 with gsoap 2.7.13 >
