https://bz.apache.org/bugzilla/show_bug.cgi?id=65159
--- Comment #11 from WJCarpenter <[email protected]> --- First a comment about my repro scenario. I used HTTP/1.0 because I wanted curl to avoid reusing the connection. Of course, we don't really see production HTTP/1.0 traffic these days (or at least not in any quantity to care about). Today I repeated the experiment but invoked curl (defaulting to HTTP/1.1) many times in a loop instead of listing the URL many times on the command line. That gave similar repro. Unique ID: ts: 3844085857d, ctr 18097d, tdx 83886080d, YRgg5a4m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3844085857d, ctr 18097d, tdx 83886080d, YRgg5a4m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3844085857d, ctr 18097d, tdx 83886080d, YRgg5a4m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3844085857d, ctr 18097d, tdx 83886080d, YRgg5a4m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3844085857d, ctr 18097d, tdx 83886080d, YRgg5a4m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3860863073d, ctr 18097d, tdx 83886080d, YRgg5q4m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3860863073d, ctr 18097d, tdx 83886080d, YRgg5q4m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3860863073d, ctr 18097d, tdx 83886080d, YRgg5q4m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3860863073d, ctr 18097d, tdx 83886080d, YRgg5q4m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3860863073d, ctr 18097d, tdx 83886080d, YRgg5q4m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3860863073d, ctr 18097d, tdx 83886080d, YRgg5q4m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3860863073d, ctr 18097d, tdx 83886080d, YRgg5q4m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3860863073d, ctr 18097d, tdx 83886080d, YRgg5q4m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3860863073d, ctr 18097d, tdx 83886080d, YRgg5q4m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3877640289d, ctr 18097d, tdx 83886080d, YRgg564m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3877640289d, ctr 18097d, tdx 83886080d, YRgg564m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3877640289d, ctr 18097d, tdx 83886080d, YRgg564m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3877640289d, ctr 18097d, tdx 83886080d, YRgg564m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3877640289d, ctr 18097d, tdx 83886080d, YRgg564m1ckw_QogJNqxRgAAAAU Unique ID: ts: 3877640289d, ctr 18097d, tdx 83886080d, YRgg564m1ckw_QogJNqxRgAAAAU As Christophe JAILLET noted last time, the counter value stays the same. It's only the tick of the clock that makes a difference. If the thread index (r->connection->id) really does reflect the worker thread, then it looks like those requests were all handled by the same thread. I can see that the counter does change for particular thread indexes outside of my testing, so it's not a case of it being completely stuck. That's interesting about it not being supported on Windows NT. I hadn't noticed that before. Somebody before my time started using this module years ago, possibly when Windows was the only supported platform for us. I agree, there doesn't seem to be any reason for that restriction with the current code, but the rest of that documentation page describes some things that are no longer true for the current code. For example, host names / IP addresses aren't part of the input any more. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
