Our read-only status monitor started pausing after detailed logging was enabled. Cell controls are separate. The busy log folder makes synchronous writing look suspicious, but I don't want to confuse that with late controller replies. How should I separate those delays?
Time receipt, parsing, write and display separately with a monotonic clock, then replay the same captured input through the application offline. A busy folder is a clue, not a timing measurement. Compare logging enabled and disabled without changing the incoming sequence at the same time.
The replay reproduces the pause with no network involved. Incoming samples reach the parser steadily, but the display callback waits for each file flush. Disabling detailed writes removes that pause in the same replay.
That's a specific local finding. If you move writing to a queue, give the queue a bound and decide what happens when the disk can't keep up. Otherwise the display improvement can simply hide a memory problem until later.
I'd keep the screen and the saved trend requirements separate. Showing the latest sample may be fine for a current-status view, but a history used for diagnosis must identify anything it didn't retain. A smooth screen can make a broken trend look wonderfully healthy.
Isaac, yes. Our maintainers look back at the saved record after the event. They need gap and overflow information there, not only a warning that flashed on a screen nobody was watching.
We chose a bounded writer queue. On overflow the monitor records a visible loss interval and dropped-record count when writing resumes; it doesn't silently pretend the trend is continuous. Current display uses the latest timestamped sample and shows age.
Test a deliberately stalled writer, then recovery, using that same input. Check the queue bound, display age and saved loss information. Normal replay performance won't establish the overflow behaviour you just described.
And test closing while writes are pending. Decide whether shutdown drains within a bound or records an incomplete tail. Don't let the last part of a diagnostic session vanish behind a clean close message.
Yes. Slow and stalled writer replays stay within the queue bound, the display remains responsive with age visible, and the saved trend records the loss interval and count. Interrupted shutdown leaves an explicit incomplete-session marker. The maintainer accepted the logging change after reviewing those files.
That resolves the flush-blocked display path you reproduced. Keep the stage timing available for future incidents; this result doesn't mean a real communication delay could never happen, only that you now have a way to distinguish it.