@Chad: should this be included in the straw poll for the architecture summit or is that too soon? D On Tue, Dec 31, 2013 at 6:55 PM, Chad <innocentkiller(a)gmail.com> wrote:

On Tue, Dec 31, 2013 at 9:55 AM, Chad <innocentkiller(a)gmail.com> wrote: Apropos of wfProfileIn/Out: "A tracing infrastructure that relies on active collaboration from application-level developers in order to function becomes extremely fragile, and is often broken due to instrumentation bugs or omissions, therefore violating the ubiquity requirement. This is especially important in a fast-paced development environment such as ours." http://research.google.com/pubs/pub36356.html It's a really cool paper. Here's how Dapper makes it possible to instrument Google's distributed infrastructure: * When a thread handles a traced control path, Dapper attaches a trace context to thread-local storage. A trace context is a small and easily copyable container of span attributes such as trace and span ids. * When computation is deferred or made asynchronous, most Google developers use a common control flow library to construct callbacks and schedule them in a thread pool or other executor. Dapper ensures that all such callbacks store the trace context of their creator, and this trace context is associated with the appropriate thread when the callback is invoked. In this way, the Dapper ids used for trace reconstruction are able to follow asynchronous control paths transparently. * Nearly all of Google’s inter-process communication is built around a single RPC framework with bindings in both C++ and Java. We have instrumented that framework to define spans around all RPCs. The span and trace ids are transmitted from client to server for traced RPCs. (cf pg 4)