https://bz.apache.org/bugzilla/show_bug.cgi?id=65159
--- Comment #6 from WJCarpenter <[email protected]> --- I don't know why the original poster saw the rare duplicates. Maybe it was unlucky timing of threads overlapping in the (critical) section in the space between grabbing the counter value and updating it. Anyhow, I think for us the fix makes the problem much worse. When we upgraded from 2.4.46 to 2.4.48, we started seeing duplicates quite often. It was noticed by a team that harvests our log records and puts them into an external DB for analytical purposes. In one case, where a security scanner kicked in, we saw 172 requests with the same unique id. I have a theory about why it's worse now, but I'm not quite sure of my Apache facts. Both before and after the patch, the thing that distinguishes one thread from another is r->connection->id. I wasn't able to track down what that "id" value actually comes from, except for a comment claiming it should be unique for all time or something like that. But suppose that "id" does not change from request to request. For example, for two consecutive requests over the same persistent TCP connection, would they have the same r->connection->id value? (That's the thing I don't know.) Before the patch, there was a single global counter and that little window of time which probably leaked duplicate unique IDs on rare occasions. After the patch, we have a counter per worker thread, and that should eliminate the problem of that little time window. But the patch initializes all of the per-thread counters to the same or similar values (the otherwise unused global counter). And that means that if r->connection->id is the same, or if it can sometimes be the same for requests handled by different threads, then there will be duplicate unique IDs within the same clock second. Anybody able to comment on my hypothesis about why this happens for us? -- 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]
