Thanks for the update. The memory limit situation only occurs when using the live logging features of TestRail (TCP/named pipes) and is not related to log files. We recommend using log files for production systems (with log rotation options etc.) as these have the lowest impact on your application. You can then just open the latest log files in the Console (even while your application is writing to them) or even write tools to analyze the log files and take further actions based on particular events (for example, it would be possible to write a tool that periodically checks generated log files for errors and then emails those errors to administrators). The log file format is fully documented and there’s also an SDK which can read SmartInspect log files:
Making the Console memory independent is currently not planned unfortunately as this would affect too many parts of the application.
Did you mean to write “SmartInspect” above - not “TestRail” ?
Your reply has confused me a bit - FYI here is the connection string used within the service startup logic of a network server of ours:
[color=red]“pipe(reconnect=true, reconnect.interval=5),file(filename=|” + logpath + “|,append=true,rotate=daily)”; [/color]
(Ignore the vertical bar - we replace that with a " char as a later step before using the string, just to ease readability of the C# source).
If we start the service it’s fine - the log file is updated and we see these within the file.
So basically we ALWAYS have and use a log file and these appear to always be correct.
However we often have the SI Console up when we start the system and so we see the logged messages in that console viewer - this is quite intuitive.
What I’m getting at here is that the eventual freeze of the console (after several days) is a bug - because we are forced to kill it via task manager - if there are some internal limits I’d expect the console to check this from time to time and behave more robustly, perhaps displaying a message box etc - but allowing us to exit it cleanly.
And to recap I don’t think it is ideal to allow the console to have any limit at all, whcy can’t that app be improved to run forever, just reading and scrolling log messages as they get added to the file by the applications?
I assumed early on that the console was just a viewer - able to scroll arbitrarily through any sized log file and automatically scroll as new messages are added.
Finally when it does freeze and we restart it (as described in the first post in this thread) the apps never seems to be able to reconnect - I am seeing if my customer can see anything in the connecttion log but yet to hear back from them on that front.
Might there be a bug in reconnect that only occurs when a console fills up and freezes and gets forcibly restarted?
Have you or can you possibly test this scenario?
Start console, start a logging app that logs a great deal, wait (even a few days if needed) for the console to freeze up, kill it then restart it and see if the app reconnects and log messages appear?
PS: Here is a typical console view of the service startup info:
As you can see important info is reported and these kinds of messages along with ocassional exceptions, status, metrics, connects, disconnects etc are often needed in an instant by support staff throught the day - the SI product does not state (so far as I can recall) that the console is not designed to run continuously and so I never conveyed that to my customers when we were desiging and putting these large mission critical systems together.