Adapted StructuredTaskScope for Context and cancellation

Wesley Hill whill at yext.com
Fri Oct 24 17:40:05 UTC 2025


>
> Thanks for writing up your experiences. What pain points would have
> remain if somehow OpenTelemetry could use ScopedValues?


Ignoring that OTel Context propagation pain point, there was the one other
pain point related to Configuration:

   - There's no accessor with which to get the timeout configured on a
   JDK's Configuration object, and
   - Configuration.withTimeout does not allow passing null to clear an
   already-set timeout.

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.

– Wesley


On Fri, Oct 24, 2025 at 11:15 AM Alan Bateman <alan.bateman at oracle.com>
wrote:

>
>
> On 24/10/2025 13:54, Wesley Hill wrote:
> > Hi, and thanks for your work on StructuredTaskScope. I recently
> > adapted it for use in our services to handle (a) propagation of the
> > OpenTelemetry Context, and (b) the richer cancellation model we use.
> > Overall it went fairly well, and I'll give a few details and some
> > minor feedback in case that's of interest.
> >
> > Background: We have an
> > implementation of io.opentelemetry.context.Context for the usual
> > purposes of passing around tracing, logging, authentication, and other
> > context. We also added a cancellation signal in that Context
> > implementation, very much along the lines of
> > grpc-java's Context/CancellableContext classes (which also makes it
> > similar to golang's Context). Cancelling a parent Context cancels all
> > the child contexts, and a Context can cancel itself when it reaches a
> > Deadline, and callbacks can be registered to run upon cancellation. We
> > do this because thread interruption alone is not a sufficient approach
> > for cancellation when we need to cancel things like HTTP or gRPC
> > calls, JDBC Statements, and other I/O which isn't interruptible. (I
> > understand that it's not a goal of the current structured concurrency
> > JEPs to improve cancellation beyond thread interruption).
>
> Thanks for writing up your experiences. What pain points would have
> remain if somehow OpenTelemetry could use ScopedValues?
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20251024/1d18afb3/attachment-0001.htm>


More information about the loom-dev mailing list