TidHTTPServer and Orphaned Connection Threads

[takyon_dg]

You're right (I thought it might create a leak).

Releasing the XMLDoc after CoUninitialize() is called is undefined behavior, anything could happen.

New Indy is in there (6.2.5499)

The current version is 10.6.2.5505.

and that line. Same problem persists.

Then please create a minimal example that reproduces the same issue and then post the code.

What I was thinking was I would track threadId's, their HTTP request and then in some other event handler, remove them from the list if they are properly closed and log the orphaned ones on a timer... I guess what I'm asking is, in terms of the TidHTTPServer events, is there (and which) one that gets triggered after the OnCommandGet (connection thread) is properly terminated/exited?

There is no event for that specific use-case. If you want to detect when a thread terminates, you need to derive a new class from TIdThreadWithTask and set the server's Scheduler.ThreadClass property, like I described earlier.

The OnDisconnect event is fired when the client connection is being disconnected and the thread that managed it is about to be cleaned up (terminated when using TIdSchedulerOfThreadDefault, put in the pool when using TIdSchedulerOfThreadPool).

I see OnContextCreated, but not sure which one might happen after.

There isn't one.

would I have to gain access to the TidSchedulerOfThreadDefault and assign a method to the AfterExecute event?

Yes. That would be the most accurate way to detect a thread terminating.

Also, is there a straight-forward way to pull the HTTP header User-Agent from TidContext in OnException?

No, because the TIdHTTPRequestInfo object is not stored in TIdContext at all. And even if it were, it would get destroyed before the OnException event is fired.

In order to access any HTTP-related values from outside of the events that provide access to them, you will have to save the values yourself. For instance, you could use the TIdContext.Data property. Or, you can derive a new class from TIdServerContext and add whatever extra members you want to it, and then set the server's ContextClass property before activating the server. You can then type-cast any the server's TIdContext objects to your custom class when needed.

I'm trying to isolate if a lot of my socket errors (including SSL handshake issues) are specific to an client OS or http control version.

Any errors you encounter during the SSL/TLS handshake will happen before any HTTP data is transmitted, since the connection has not been secured yet. But once the handshake is complete, any subsequent SSL/TLS errors would happen during HTTP I/O.

All the exceptions I have here seem to occur before OnCommandGet which I imagine means the datastream has not been identified/parsed as HTTP.

A LOT of things happen before the OnCommand... events are fired. There is not a good way to know at which stage exactly (SSL/TLS handshake, reading/parsing HTTP headers, reading/parsing HTTP body).

My past attempts showed nothing in the input buffer to record

OpenSSL has direct access to the socket connection and performs its own socket I/O. The only data that ever reaches the IOHandler's InputBuffer is the data that OpenSSL has decrypted.

and I wasn't sure what would happen if I try to use any of the read functions (AContext.Connection.Socket....)

The socket has already been closed by the time the OnException event is fired, so whatever data would be in the IOHandler's InputBuffer would be what has already been read from the socket and decrypted. And if you try to read from the socket directly, that would be encrypted data.

---

Dang it. Lost my message.

In short. Thanks. I can't reproduce in a development environment. Only live. The code I wrote is the basic structure as it exists, but I'll try the absolute most recent build of Indy and I'll take the actual (OnCommandGet) method and strip it of the business logic and perhaps something will reveal itself that helps explain how some of these threads seem to be persistent.

I'll be back.