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 · 2026年3月21日 07:48 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
7 条回复
Time acquisition, file writing and display update separately. Keep that timing capture off the suspect destination.
9分Saved-response replay stalls too, with prompt reads; the long interval is inside the synchronous file write.
20分Then move persistence off that display path. Bounded queue, visible failure handling.
14分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.
-2分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.
4分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.
12分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.
13分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .