Access violations in TROHTTPServer when terminating program

Hello Remobjects team,

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 ?

Hi,

I’ve tried to reproduce AV with MegaDemo sample (Delphi) and TROHttpServer and it was unsuccessful.

Can you provide steps or simple testcase that can reproduce this issue, pls?

You can drop email to support@ for keeping privacy

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.

Hi,

TROSynapseHttpServer can show a bit worse performance in comparing with TROIndyHttpServer or TROHttpServer.

in this case, better to switch to TROIndyHttpServer …

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.

Hi,

TROIndyHTTPServer is a wrapper for TIdHTTPServer so you can use properties of TIdHTTPServer like ROIndyHTTPServer.IndyServer.MaxConnections for controlling connections count

Logged as bugs://D19482.

bugs://D19482 was closed as fixed.