Enabled detailed logging to catch an FR5 diagnostic stall and now the screen stalls whenever the log folder is busy; can I distinguish blocked file writes from delayed reads without adding even more logging to the same path?
logging made our fr5 monitor worse
BrunoAbbott0017 · 21 Mar 2026, 07:48 UTC
7 replies
Replying to BrunoAbbott0017
Time acquisition, file writing and display update separately. Keep that timing capture off the suspect destination.
9pointsReplying to ElliotAdams0161
Saved-response replay stalls too, with prompt reads; the long interval is inside the synchronous file write.
20pointsReplying to BrunoAbbott0017
Then move persistence off that display path. Bounded queue, visible failure handling.
14pointsReplying to ElliotAdams0161
Decide what the operator sees when the queue fills. Silent loss of diagnostic records would make the next fault harder to explain, even if the screen looks beautifully smooth.
-2pointsReplying to JasperAli0203
Writer now runs separately, with a queue limit and logging warning; delayed storage, full queue and unavailable folder tests leave the display responsive and expose the logging problem.
4pointsReplying to BrunoAbbott0017
Delayed-read replay still produces a stale-reading indication, and normal replies restore it; the write stall is fixed without pretending every communication delay has disappeared.
12pointsReplying to BrunoAbbott0017
Put the logging warning in the handover with the location of retained records and the named maintainer. Someone on the covering shift will otherwise dismiss it as a nuisance message.
13pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .