1

I know, from a lot of other questions here, that Indy TCP Server relies on exceptions to clean the connections after use.

I have a server in my hands that was coded in a way that the exceptions are handled by the code and are not re-raised for Indy.

In a ideal world, I would rewrite it to satisfy this requirement. I am, sadly, in a real world, and do not have the time nor the human resources required for such fix in a time it need to be fixed.

The server and the connection have one interesting property, however: the processing happen entirely in one OnExecute run. This means that I know for a fact that at the end of the OnExecute procedure, the connection must have been closed and it is not expected for the client to be connected yet.

So, I'm thinking of doing a simple dirty trick: At the end of the OnExecute code, instead of simply returning, I can raise a generic Indy exception, like EIdException, so that Indy catches it and do its clean process.

So, my question is if, for Indy to clean the connection, does it matter what exception is raised from OnExecute? Can I raise EIdException, or for this case it is better to raise any other of Indy's exceptions?

Note that what I'm asking is if I can swallow all exceptions and raise a new one at the end, instead of the suggested path of re-raising the exception.

ricardomenzer
  • 268
  • 3
  • 16
  • 1
    Task Manager does not detect memory leaks, and what you've described does not indicate a memory leak. The Delphi memory manager allocates memory in blocks, and when an object is freed (correctly), the memory it used remains in that block; the memory manager does not give it back to the OS once it's allocated by the memory manager. – Ken White Apr 18 '21 at 23:28
  • @KenWhite I know. I'm using fastMM to detect leaks. I suspect that memory fragmentation is causing this increase. What you're telling is that the memory usage will increase up to a certain point and the stabilize because the memory manager will reuse its own blocks instead of getting more from the OS? – ricardomenzer Apr 19 '21 at 03:22
  • I didn't say *stabilize* - that would depend entirely on your code. My point was that Task Manager does not provide any meaningful information about memory leaks. FastMM would be the only accurate way to detect them - you should ignore anything that Task Manager says. And yes - the Delphi memory manager will reuse blocks when it can, but if those blocks run out it will reallcate a larger block. – Ken White Apr 19 '21 at 03:25
  • Just to clarify: I was not relying on task manager to look for leaks. I'm looking in fastMM reports for that (and they are clean). But taskmanager is showing my process getting bigger in memory consumption (to put the numbers: at a fresh start, about 6MB. After a couple of days and some hundreds of thousands connections, about 25MB). At first i thought it was Indy waiting for the exception to clean, but this is clearly not the case now that Remy answered. My other line of thought is some kind of fragmentation, which I have to look further. – ricardomenzer Apr 19 '21 at 03:34
  • I've based both of my previous comments on this text from your question: *I can see the memory usage growing (not that fast) in task manager.*. Your question text makes no mention of FastMM or using it for memory leak detection. If that's what you were asking about, the text should have said so. :-) Again, ignore whatever you think Task Manager is telling you as far as whether there are any leaks or not - it's output is meaningless in that regard. – Ken White Apr 19 '21 at 03:38
  • I opted to remove that part over edit. Just for completeness, this is how I would write the edit: Today, after many clients connections and disconnections, my server have no memory leaks, as reported by FastMM, which I am using as the memory manager. However, when I look in Task Manager, I can see the memory usage growing (not that fast). I suppose that this is caused by the server not receiving the exceptions, and thus not doing its internal clean up until I close the server application, making the server component to clean. This would explain the no leaks but memory growing while running. – ricardomenzer Apr 19 '21 at 11:35

1 Answers1

4

TIdTCPServer does not require an exception to be raised. IF an exception is raised, the server will catch the exception and fire its OnException event. But cleanup is performed whether or not an exception is raised. If you ensure the connection is closed properly before the OnExecute event exists, so be it. As long as you see the server firing its OnDisconnect event, then all is good.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • Good to know. In fact, the OnDisconnect event is firing. The memory increase problem may be related to another part, unrelated to Indy. I suspect of some kind of fragmentation. I will look further in that. – ricardomenzer Apr 19 '21 at 03:20
  • By the way, today I'm calling ```AContext.Connection.Disconnect(true)``` at the end of ```OnExecute``` to finish the connection. Is this the right way to do it? Is there any other better/recommended way? – ricardomenzer Apr 19 '21 at 03:24
  • 2
    @ricardomenzer `AContext.Connection.Disconnect()` will work just fine. – Remy Lebeau Apr 19 '21 at 04:10