bugdude

First off, thanks for answering. You're right on #1, but I do have a fair number of patched up open sourced but abandoned controls that are tricky to get up and running on each new version. I'll try installing community ed on another system with just the controls for this and see if using updated tools resolves this (should've thought of that sooner). Since I added openSSL to a tool originally built without it you're probably right that I have some errant thread shutdown issues (of my own creation). The connection is a long lived websocket connection (just one), but with the client hitting so often I think it gets hit again before the shutdown waittimes can expire and may be talking to a partially torn down object. That was why I wondered if there was a 'clean' way to abort/disconnect the SSL connection from the server side that could be used before trying to set active false on the server.

I am a hobbyist on a budget, so I use dated versions of Delphi and Indy (10.3.3 Delphi and the included Indy). I ran into problems with a project which uses TidCustomTCPServer to implement a web server with websocket support using OpenSSL. Basically the issue is that if the server has an active SSL websocket connection and TCPServer.Active is set false, the application stalls and gets locked into a loop in Indy (I think). Looking in the debugger I see that even though StopListeners was already called the recv handler is still being called repeatedly and generating exceptions. The browser code polls the server every 100ms for screen updates so the calls may originate from the client, but the connection does still seem to be active. (project based on sourceforge ThinVNC with SSL added and other things added). saw some notes about this issue in issue in GitHub, but I tried the solution mentioned there and that alone did not help.. (replaced call to AContext.Connection.Disconnect with Binding.CloseSocket call) Q1 - is there a particular code sequence I could follow to block out those active SSL connections before setting active False that would circumvent this problem without upgrading Indy ? Q2 - would upgrading Indy from GitHub fix this specific issue ? Q3 - would the Indy cleanup script work on Delphi 10.3.3 safely ? Q4 - is upgrading Indy likely to break anything else in this older version of Delphi ? Any other ideas or suggestions would be appreciated.. it works partially and I would like to get it stable...