https://bz.apache.org/bugzilla/show_bug.cgi?id=65159

--- Comment #18 from WJCarpenter <bill-apa...@carpenter.org> ---
(In reply to Michael Kaufmann from comment #16)
> Note that 16777216 is htonl(1) and 83886080 is htonl(5) on x86, so these are
> the threads with index 1 and index 5.

This was an interesting insight that got me to thinking. I added some things to
what I have been printing for each call.

    //    ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(01560)
    fprintf(stderr,
                 "Unique ID: ts: %u, ctr %u -> %u, tdx %u -> %u -> 0x%x, %s\n",
            new_unique_id.stamp,
            new_unique_id.counter, ntohs(new_unique_id.counter),
            new_unique_id.thread_index, ntohl(new_unique_id.thread_index),
thread,
            str);

In addition to decoding back to host format of the counter value and the thread
index, I also print the address of the apr_thread_t object for the current
thread. I again cranked down my thread pool to just 6 threads and re-ran my
curl-based test. Here are a couple examples of duplicates that cropped up:

Unique ID: ts: 1472666209, ctr 60362 -> 51947, tdx 0 -> 0 -> 0x459b7618,
YRrHVxmnrp_KPQCePqHK6wAAAAA
Unique ID: ts: 1472666209, ctr 60362 -> 51947, tdx 0 -> 0 -> 0x45eec678,
YRrHVxmnrp_KPQCePqHK6wAAAAA

Unique ID: ts: 499587681, ctr 60362 -> 51947, tdx 33554432 -> 2 -> 0x459bb638,
YRrHHRmnrp_KPQCePqHK6wAAAAI
Unique ID: ts: 499587681, ctr 60362 -> 51947, tdx 33554432 -> 2 -> 0x45f06748,
YRrHHRmnrp_KPQCePqHK6wAAAAI

For those pairs of requests, the thread index is the same, but the address of
the apr_thread_t object is different. This was seen among many normal-looking
entries that were enough to convince me that the apr_thread_t address that I
was printing was legit. Since it looks like r->connection->id is an index into
some table, something in Apache code is moving entries around in that table. It
is, therefore, not a very good choice as a proxy for the thread identity.

BTW, the movement of threads in the table is not stress-related. I also saw it
happen in during mostly idle times when the server was only seeing some
lightweight status check requests once every few seconds.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

Reply via email to