Join 34,000+ subscribers and receive articles from our blog about software quality, testing, QA and security.

TCP reconnect broken connection


I try to use the “reconnect” feature over TCP connection. The amount of time used in case of broken connection (the console is not started) is too big, even if the quantity of logging is smallest.

Connections = file(append="true", filename="log.sil", maxsize="0", rotate="daily", backlog="0", caption="file", flushon="error", keepopen="false", level="debug", reconnect="false"), 
tcp(host="localhost", port="4228", timeout="30000", backlog="0", caption="tcp", flushon="error", keepopen="false", level="debug", reconnect="true")

Is timeout parameter the one that influence? I try with 300 and 30000 and the effect is same.



I think the best solution for the feature is to not try to reconnect to the all log send statement but use some timer to verify if the TCP connection can be used. Else in case of send 1000 line of logging the result additionally 1000*300 ms, time that seam too big


Can you reproduce this situation ?



Hello Aurelian,

This is the standard behavior of the TCP protocol. The TCP transport layer has a few problems when trying to provide a fast reconnect option. An unsuccessful connection attempt can easily take from a few milliseconds to even seconds. The timeout option can be used to minimize this time but even if you specify, say 100ms, for this option this is still a lot of time when you consider that the reconnect option attempts to reconnect for each log statement.

To solve these problems, SmartInspect 3.0 will introduce three new features:

  • A new default logging protocol which uses named pipes for local live-logging to the Console. Besides being faster (factor 2-3) than TCP for local logging, named pipes have the huge advantage that a reconnect attempt is very fast. This makes the reconnect option usable even for production systems.

  • A new protocol reconnect interval option. With this new option, you can specify that a reconnect attempt should not be initiated for each log packet but only in a specified interval. For example, you can specify that the reconnect option should only initiate a reconnect attempt once every 10 seconds or every minute. This minimizes the time spent in unsuccessful reconnect attempts.

  • A new option for asynchronous logging. When asynchronous logging is enabled, all I/O related operations like (re-)connecting or writing a log packet are executed in a background thread and do not block the application anymore.



You right with the TCP protocol to needs to specify the timeout interval, (I supposed you based on indy TCP connection) , but I think this kind of error necessities one urgently patch. For any application that use the “reconnect” options this can block the application and the error is very difficulty to found.

There is also memory leak in this case



Hello Aurelian,

This behavior is actually well documented. I admit though that the usefulness of the TCP reconnect option is currently limited to development systems. A simple patch for the current version would be difficult since it, as noted above, involves several architecture changes (asynchronous logging, reconnect interval and so on) which need extensive testing. The 3.0 is around the corner anyway and will be free for customers with an active support plan.

By the way, we are not using Indy for our TCP layer in the SmartInspect libraries to avoid the huge dependency (having Indy as dependency for deployable libraries can be a nightmare). We wrote a simple and lightweight TcpClient class directly around the WinSock API which does the low-level TCP work.

I will look into it, thanks. Did you use FastMM to find this?