I’m getting access violations when I close a server application that contains a tROHttpServer. I use the preview build 1595 because it solves some issues of the previous build.
The access violations usually happen in tROSocket.ResetLastError() and in TROAsyncContext.DoRead(). According to FastMM4 the access violations are of the type “use after free”.
I realize that shutting down a server whilst it is being accessed by clients is a complicated matter. Is there a way to shutdown tROHttpServer “gracefully”, by telling it to not accept any more connections and maybe even finishing the requests already in the queue ?
Sorry, I can’t, the prerequisites are that many connections are established and that the server application closes whilst communicating data. This is not easily reproduced in a test case, timing may be an issue. FastMM4 (full debug mode) tells me that the methods mentioned aboved were called (async?) after the http server was already freed.
I have now switched to tROSynapseHttpServer and so far it hasn’t happened anymore, also the CPU load of my application has gone down noticeably so I’ll probably stick with that server type.
I can try, but how do I manipulate the thread pool parameters (maxthreads, Poolthreads, MaxQueue) of tROIndyHTTPServer? It has no published property “ThreadPool”.
My service gets hammered with many concurrent requests.
TROIndyHTTPServer is a wrapper for TIdHTTPServer so you can use properties of TIdHTTPServer like ROIndyHTTPServer.IndyServer.MaxConnections for controlling connections count