Memory leak in unbounded async "stack"

[pauldraper]

From discussion opentracing/specification#23 (comment)

void main(ExecutorService executor) {
  executor.submit(new Runnable {
    public void run() {
      Thread.sleep(1);
      main(executor);
    }
  })
}

// okay
main(Executors.newSingleTheadExecutor());
// memory leak
main(SpanPropagatingExecutors.newSingleThreadExecutor(DefaultSpanManager.getInstance));

I'd prefer to keep the "stack tracking" on the actual stack, not LinkedSpanContexts.

I suggest simplifying the interface to.

public interface SpanManager {
  Span currentSpan();
  void execute(Span span, Runnable f);
  void <T> execute(Span span, Callable<T> f);
}```

This will allow the context to get reset after the code of interest is done, but it's impossible to have a memory leak (at least, not without having stack overflow).

[sjoerdtalsma]

The short answer to this is "then don't use a stack" in this case.
I find the stack behaviour to be very intuitive.
Yes there are caveats, but I'd argue having ThreadLocals in there form the greatest risk in general.
As far as I know @bhs is working on integrating the propagation concept in the spec itself. That may be an opportunity to probably document this better.

Meanwhile, if you have a use-case like you showed above, use your own SpanManager implementation that doesn't do stacks.

[pauldraper]

Make sense, just wanted to make sure that limitation/caveat is noted.

(FYI, spanmanager project is definitely great, and I've been using it a lot...which is the only way I ever noticed this.)