curious if there is a Local.java in the works for CompletableFutures like scala has

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

curious if there is a Local.java in the works for CompletableFutures like scala has

Dean Hiller
Way more detail here...

http://stackoverflow.com/questions/37933713/does-completablefuture-have-a-corresponding-local-context

So I was wondering if this was going to be added at some point to the jdk
as I could not figure out how to set something so it was still available on
the thread at a later time when traversing async thenCompose, thenAccept.

thanks,
Dean
Reply | Threaded
Open this post in threaded view
|

Re: curious if there is a Local.java in the works for CompletableFutures like scala has

Pavel Rappo
General questions on concurrency in Java should be asked here:

   http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

> On 18 May 2017, at 21:57, Dean Hiller <[hidden email]> wrote:
>
> Way more detail here...
>
> http://stackoverflow.com/questions/37933713/does-completablefuture-have-a-corresponding-local-context
>
> So I was wondering if this was going to be added at some point to the jdk
> as I could not figure out how to set something so it was still available on
> the thread at a later time when traversing async thenCompose, thenAccept.
>
> thanks,
> Dean

Reply | Threaded
Open this post in threaded view
|

Re: curious if there is a Local.java in the works for CompletableFutures like scala has

Martin Buchholz-3
There's not likely to be any support for local context anywhere in
java.util.concurrent, but it seems not too hard to roll your own support
with a custom executor to be used with CompletableFuture that kept track of
any local context.

On Fri, May 19, 2017 at 1:16 PM, Pavel Rappo <[hidden email]> wrote:

> General questions on concurrency in Java should be asked here:
>
>    http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> > On 18 May 2017, at 21:57, Dean Hiller <[hidden email]> wrote:
> >
> > Way more detail here...
> >
> > http://stackoverflow.com/questions/37933713/does-
> completablefuture-have-a-corresponding-local-context
> >
> > So I was wondering if this was going to be added at some point to the jdk
> > as I could not figure out how to set something so it was still available
> on
> > the thread at a later time when traversing async thenCompose, thenAccept.
> >
> > thanks,
> > Dean
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [concurrency-interest] curious if there is a Local.java in the works for CompletableFutures like scala has

Pavel Rappo
Heya Josh,

I only want this question to be discussed on ci rather on core-libs-dev :-) I'm not the OP.

> On 22 May 2017, at 23:01, Josh Humphries <[hidden email]> wrote:
>
> Pavel,
> It sounds like you want

[...]
Reply | Threaded
Open this post in threaded view
|

Re: [concurrency-interest] curious if there is a Local.java in the works for CompletableFutures like scala has

Dean Hiller
In reply to this post by Martin Buchholz-3
All, this post is all about 3rd party code that I do not control so
therefore the solutions above do not work as those libraries may predate my
library.  more specifically.....

Martin,
   If I roll my own slf4j MDC only works in my code and stops working in
3rd party code!  because the 3rd party code does not transfer the context.

Viktor,
  You hit the head on the nail with "It's easy to lose context when
intermediate libraries/Executors".  This is solved on twitter futures until
we hit libraries not using twitter futures because no matter the executor,
the future transfers the context for us the way it was written.

   "It's unclear what fan-in behaviors like zip, merge etc mean in terms of
what the local values should be?"
This is a very good question.  I wonder what twitter futures do here.  I
would be ok with dropping the context in this case or combining it.  I do
not really care yet here since I have not run into it but it is a very good
question and would need a lot of thought

Josh,
   I cannot expect all 3rd party libraries that are brought in will be
using ContextPropagatingExecutor so that solution breaks down as Viktor
eludes to.

Alex,
   tuples do not solve the issue.  in fact twitter futures have a
Local.scala file that does solve the issue.  The main issue is 3rd party
code and having the context continue into "unknown code" using
CompletableFuture.  I cannot control that code BUT want every log.info in
that code to use and log the request id.  it is awesome at twitter as I can
just follow that request id in the logs.  If CompletableFuture had such a
context, I could transfer this info into it and into the 3rd party java
libraries.

I am writing a webserver for fun based on CompletableFutures and therefore
cannot control the controllers as the app developer writes that and the
request id stops getting logged on the request path which is mostly
.thenApply and .thenCompose.  even if the Controllers do you my future,
they will bring in libraries NOT using my future :(

thanks
Dean





On Tue, May 23, 2017 at 3:12 AM, Alex Otenko <[hidden email]>
wrote:

> Why would someone want to rely on state they cannot control?
>
> Is the idea to subvert some API that does not provide a way to pass state?
> This is strange especially in the context of Scala, where you can easily
> form tuples.
>
> Alex
>
> On 22 May 2017, at 20:44, Martin Buchholz <[hidden email]> wrote:
>
> There's not likely to be any support for local context anywhere in
> java.util.concurrent, but it seems not too hard to roll your own support
> with a custom executor to be used with CompletableFuture that kept track of
> any local context.
>
> On Fri, May 19, 2017 at 1:16 PM, Pavel Rappo <[hidden email]>
> wrote:
>
>> General questions on concurrency in Java should be asked here:
>>
>>    http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>> > On 18 May 2017, at 21:57, Dean Hiller <[hidden email]> wrote:
>> >
>> > Way more detail here...
>> >
>> > http://stackoverflow.com/questions/37933713/does-completable
>> future-have-a-corresponding-local-context
>> >
>> > So I was wondering if this was going to be added at some point to the
>> jdk
>> > as I could not figure out how to set something so it was still
>> available on
>> > the thread at a later time when traversing async thenCompose,
>> thenAccept.
>> >
>> > thanks,
>> > Dean
>>
>>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>