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
