Measure before and after the receive, write and display update separately; are you currently timing just the combined callback?
简体中文界面。帖子、指南及政策正文保留原文;未对原文作自动翻译。
Can't blame the network while our log callback blocks
LeahBennett0756 · 2025年6月26日 08:22 UTC
14 条回复
Only the combined callback. Rotation also renames the old file inside it. I'll have the developer time those operations separately rather than call the whole interval communication delay.
14分Try the same replay with rotation disabled as a comparison, keeping everything else the same. Doesn't make disabling rotation a fix. It just gives you a way to see whether that particular work is involved.
13分Can that comparison use an isolated test folder so the ordinary logs aren't lost? I mean the replay files, not the records from actual operation.
7分Yes, separate replay output. Wasn't suggesting turn off the live records. Leah already said replay, but worth being explicit about which destination gets changed.
18分Separate replay folder used. The long duration sits in rotation and writing; receive timing stays similar in both runs. Developer is moving that work off the display callback.
9分What will the screen say while recording falls behind? I'd like someone to be able to distinguish old displayed data, delayed logging and an actual lost connection without reading three separate support notes.
14分Does the last displayed reading currently have an age?
7分No age at present. We are adding one, plus a separate recording status; the current connected label has been carrying too many meanings.
17分Will the writer have a queue limit, and what will happen at that limit? Moving the wait elsewhere could otherwise just hide a growing pile of unsaved data.
23分Bounded queue proposed. Recording faults will be visible. The team still needs to agree which diagnostic samples may be dropped and which events must be retained.
16分Good question to settle before somebody tests with an empty queue and declares victory. Try a slow destination long enough to fill it, then close the application with unsaved work remaining.
7分The full-queue test exposed a shutdown hang. That's now on the developer's list; display timing improved, but we aren't releasing this version to maintenance yet.
7分Who owns the unsaved data at shutdown? I'd want the person closing it to know whether they're waiting, abandoning diagnostic samples, or leaving a recording fault for someone else.
6分讨论已关闭
此讨论已连续六个月没有活动,现已关闭新回复。 最后活动: .