<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks for writing up your experiences. What pain points would have<br>remain if somehow OpenTelemetry could use ScopedValues?</blockquote><div><br></div><div>Ignoring that OTel Context propagation pain point, there was the one other pain point related to Configuration:</div><div><ul><li>There's no accessor with which to get the timeout configured on a JDK's Configuration object, and</li><li>Configuration.withTimeout does not allow passing null to clear an already-set timeout.</li></ul>So we would still need our own copy of the Configuration class to manage the fact that we want to know the timeout to set the Deadline on our Context, and we don't want to pass the timeout down to StructuredTaskScope since we're managing cancellation our way.</div><div><br></div><div>– Wesley</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Oct 24, 2025 at 11:15 AM Alan Bateman <<a href="mailto:alan.bateman@oracle.com">alan.bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 24/10/2025 13:54, Wesley Hill wrote:<br>
> Hi, and thanks for your work on StructuredTaskScope. I recently <br>
> adapted it for use in our services to handle (a) propagation of the <br>
> OpenTelemetry Context, and (b) the richer cancellation model we use. <br>
> Overall it went fairly well, and I'll give a few details and some <br>
> minor feedback in case that's of interest.<br>
><br>
> Background: We have an <br>
> implementation of io.opentelemetry.context.Context for the usual <br>
> purposes of passing around tracing, logging, authentication, and other <br>
> context. We also added a cancellation signal in that Context <br>
> implementation, very much along the lines of <br>
> grpc-java's Context/CancellableContext classes (which also makes it <br>
> similar to golang's Context). Cancelling a parent Context cancels all <br>
> the child contexts, and a Context can cancel itself when it reaches a <br>
> Deadline, and callbacks can be registered to run upon cancellation. We <br>
> do this because thread interruption alone is not a sufficient approach <br>
> for cancellation when we need to cancel things like HTTP or gRPC <br>
> calls, JDBC Statements, and other I/O which isn't interruptible. (I <br>
> understand that it's not a goal of the current structured concurrency <br>
> JEPs to improve cancellation beyond thread interruption).<br>
<br>
Thanks for writing up your experiences. What pain points would have <br>
remain if somehow OpenTelemetry could use ScopedValues?<br>
<br>
-Alan<br>
</blockquote></div>