DELPHI XE 15.0.3953.35171 ROSDK 6.0.55.957,
Tested on:XP SP3/Win Server 2003 SP2/Win Server 2008
Please first run newserver.exe , run multiple clients test and select same Channel
All HTTPChannel and ROIndyTCPChannel is an error,
Sometimes you can retry, Sometimes you can not retry
ROSynapseHTTPChannel Exception:Unable to connect to remote server
ROIndyHTTPChannel/ROIndyTCPChannel Exception:
Socket Error #10048 Address already in use.
ROWinInetHTTPChannel Exception:
A connection with the server could not be established
This is nothing to do with RO it is to do with a limit to how many sockets windows can have lying around at any given time.
Your example can be made to work far more reliably and faster by setting the following on both the server and client.
Try this on the TROIndyTCPChannel/Server and you will see the difference.
DisableNagle=True (This one increases speed)
KeepAlive=True (This one increases speed and stops the error)
The reason the super channels do not exibit the error is because keepalive is true by design. therefore this error cannot happen.
You cannot retry in your example because the error is still there. Windows cannot create any more connections. If you wait for a few minutes before pressing the retry button you may be successful.
The indyHttpChannel does appear to have a bug. Although you are setting the keepAlive flag on the client, it has no effect on the TidHttp component handling the connection.
Add the following code to uROIndyHttpChannel, this allows your test to run fast and without the error.
line = 261-266 uROIndyHttpChannel.pas
procedure TROIndyHTTPChannel.SocketConnected(Sender: TObject);
begin
if DisableNagle then Indy_DisableNagle(IndyClient);
if KeepAlive then IndyClient.Request.Connection := ‘Keep-Alive’; <<<—Add this.
end;
Remobjects will need to fix this officially as it looks very much like a bug.
I’m change uROIndyHttpChannel.pas, but frequent still Exception “Socket Error #10048 Address already in use.” wait for a few minutes can retry, you are right!!
but “Socket Error #10048” very frequent and retry need wait for long time
You will need to add the ro source directory to your library path. It looks like the change is not being compiled into your app. You cannot get this error unless the connection is created and dropped for every request.
Your test is not a real world test. Calling the server thousands of times until no more sockets can be created is not something that would happen in a production server unless it had a phenominal number of clients. In which case a change of design would be necessary, load balancing springs to mind.
If you try the same test with the server and client on different machines, it will take much longer to see the error, that is simply because the throughput is not as great. The same test across the internet will require a large number of clients before you see the problem, because the internet has more latency.
There is nothing wrong with load testing but don’t think that this will be a problem in a real world scenario.
Yes, remobjects would need recompiling. Not difficult though and I always do anyway to enable indy at design time.
If you only use TDataSnapProvider and TClientDataSet with the RODatasnap then you won’t have a problem. It is only the delphi transport protocol for datasnap which has the dependency on Indy. If you don’t use it you can do without because Remobjects replaces it.
I own delphi XE but not XE2 so what I’m saying may not be true in XE2 but I can’t see any reason why not.
If upgrade INDY Development Snapshot RemObjects SDK need Recompile?
If you change minor version of indy, say from 10.5.5 to 10.5.8 - you need to recompile RO Indy package for avoiding problems with reading properties of Indy components from .dfm.
By other hand, if you have no such problems, you can skip recompiling of RO Indy package
You cannot retry in your example because the error is still there. Windows cannot create any more connections. If you wait for a few minutes before pressing the retry button you may be successful.
The indyHttpChannel does appear to have a bug. Although you are setting the keepAlive flag on the client, it has no effect on the TidHttp component handling the connection.
Add the following code to uROIndyHttpChannel, this allows your test to run fast and without the error.
line = 261-266 uROIndyHttpChannel.pas
procedure TROIndyHTTPChannel.SocketConnected(Sender: TObject);
begin
if DisableNagle then Indy_DisableNagle(IndyClient);
if KeepAlive then IndyClient.Request.Connection := ‘Keep-Alive’; <<<—Add this.
end;
Remobjects will need to fix this officially as it looks very much like a bug.
Regards,
Will.
Thanks for the report and fix, the issue is logged as #52343.