https://bugs.kde.org/show_bug.cgi?id=525021
--- Comment #1 from Branislav Klocok <[email protected]> --- A correction to the model in my description, from later measurements taken through a client that waits for its replies. The descriptor count tracks the number of conversation requests outstanding at any one moment, not the number of distinct conversations requested within a rolling window. My original measurement fired 300 requestConversation calls in about 100 milliseconds and never drained the replies, so all 300 were outstanding at once, and the apparent 30 second retention was simply how long they stayed unanswered. Measured since, through a client that lets each conversation complete before issuing the next: 533 thread heads via requestAllConversationThreads: no growth at all, flat at 30 descriptors 50 distinct threads, 6 requests in flight: baseline 31, peak 37, back to baseline in about 10 s 200 distinct threads, 6 requests in flight: baseline 31, peak 44 200 distinct threads, 2 requests in flight: baseline 30, peak 32 So the enumeration path is not implicated at all, and a client that bounds its in flight requests cannot reach the limit no matter how many threads it walks. What crosses it is an unbounded burst, which is exactly what the attached reproducer does and what the steps to reproduce describe, so the crash and the repro still stand. Only the characterisation changes: the quantity to bound is outstanding requests, which is what the expected result already asks for. I am flagging it because the summary line as written suggests a time based mechanism that is not there, and because it narrows who is affected: only clients that fire and forget. -- You are receiving this mail because: You are watching all bug changes.
