Patrick Mylund Nielsen
To be fair, if each request is handled by a goroutine like it is in
net/http, it's not that arbitrary. This is just something Go doesn't
let you access (anymore) because associating stuff with a thread ID
can cause problems in other cases.
In both DB clients and DB servers I've written in go, there's not a
1:1 correlation of requests and goroutines.
A single request to seriesly, for example, will be serviced by
hundreds of short-lived goroutines in practice.
A single HTTP request to a server to pull stats from a couchbase
cluster will be aggregating results from all of the nodes concurrently
and could very well reconfigure itself due to a cluster topology change
during that request. Some of those connections may service other
requests on the same goroutine they will be servicing mine both before
and after mine.
CBFS, where I've got the most benefit from logging as it's very often
operating on more than one node at a time required me to do a lot of
work to supply user context into log entries (most often the unique
object ID). An incoming request pushing in a new item builds a pipe and
has a goroutine copying the input from the HTTP socket to another
"frames" socket targeting another node. This one connection is serviced
by one goroutine that's moving bytes in one direction across the TCP
socket. Another is moving bytes the other direction. Multiple
concurrent HTTP connections are sending data across this TCP connection
and the requests are interleaved on the TCP stream. At the end of a
particular upload, two nodes log the arrival of a new blob of which
they've independently calculated a SHA-1 and after successfully
registering themselves with the metadata service, they log that that
particular user-named file has arrived with this hash and then
(optionally) asynchronously begins to tell a third node to ask one of
the first two for a copy of this data for itself.
It's not clear to me how any magic the logging decides to introduce
will help me in any of these cases.