Getting Indy Error "Could not bind socket. Address and port are already in use"

Question

I have developed a Delphi web server application (TWebModule). It runs as a ISAPI DLL on Apache under Windows. The application in turn makes frequent https calls to other web sites using the Indy TIdHTTP component. Periodically I get this error when using the TIdHTTP.get method:

Could not bind socket. Address and port are already in use

Here is the code:

  IdSSLIOHandlerSocket1 := TIdSSLIOHandlerSocketOpenSSL.create(nil);
  IdHTTP := TIdHTTP.create(nil);


  idhttp.handleredirects := True;
  idhttp.OnRedirect := DoRedirect;
  with IdSSLIOHandlerSocket1 do begin
    SSLOptions.Method := sslvSSLv3;
    SSLOptions.Mode :=  sslmUnassigned;
    SSLOptions.VerifyMode := [];
    SSLOptions.VerifyDepth := 2;
  end;
  with IdHTTP do begin
    IOHandler := IdSSLIOHandlerSocket1;
    ProxyParams.BasicAuthentication := False;
    Request.UserAgent := 'Test Google Analytics Interface';
    Request.ContentType := 'text/html';
    request.connection := 'keep-alive';
    Request.Accept := 'text/html, */*';
  end;
  try
    idhttp.get('http://www.mysite.com......');
  except
    .......
  end;
  IdHTTP.free;
  IdSSLIOHandlerSocket1.free;

I have read about the reusesocket method, which can be set on both the TIdHttp and TIdSSLLIOHandlerSocketOpenSSL objects. Will setting this to rsTrue solve my problems? I ask because I have not been able to replicate this error, it just happens periodically.

Other considerations:

• I know multiple instances of TWebModule are being spawned.
• Would wrapping all calls to TIdHttp.get within a TCriticalSection solve the problem?

UPDATE: After doing more searching on the internet I came across this: link text

When I do a netstat -n I too get a bunch of entries with status "CLOSE_WAIT".

Answer 1

Try to allocate a high port number. Hooking low (0..1023) ports requires admin rights IIRC.

Forget it, my bad. tidhttp is the client, not the server.

Yes, it sounds like multiple threads try to use the same tidhttp.

A cricial section would work, but effectively serialize the result. If that is a problem, use a pool of tidhttp clients.

Answer 2

I actually finally figured this out. Turns out I was NOT freeing the TIDHttp object. In my prototype example it shows it is. But my actual source code uses objects and the code where the idhttp object is freed is contained in a destructor not properly marked with override. So it was never called.