Can't blame the network while our log callback blocks
LeahBennett0756 · 26 Jun 2025, 08:22 UTC
14 replies
Measure before and after the receive, write and display update separately; are you currently timing just the combined callback?
10pointsOnly 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.
14pointsTry 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.
13pointsCan 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.
7pointsYes, separate replay output. Wasn't suggesting turn off the live records. Leah already said replay, but worth being explicit about which destination gets changed.
18pointsSeparate 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.
9pointsWhat 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.
14pointsDoes the last displayed reading currently have an age?
7pointsNo age at present. We are adding one, plus a separate recording status; the current connected label has been carrying too many meanings.
17pointsWill 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.
23pointsBounded 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.
16pointsGood 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.
7pointsThe 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.
7pointsWho 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.
6pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .