Hey, I've a service which is calling multiple other ones. For logging and tracing we utilize zipkin. Now we would like to make the calls to the other services in parallel - is there a way to do that? With coroutines I lose the information stored in ThreadLocal - any ideas/suggestions?

We’ve done that kind of thing with ThreadPoolExecutor services

Thanks a lot for your awesome support http4k

@DanielZ FYI - we've internalised the messy ThreadLocal calls from the example into a wrapper for an ExecutorService - there's now just a handy extension function

ExecutorService.withRequestTracing()

which should make things a lot neater! We've updated the example and have released this extension function as a part of http4k v5.8.2.0. 🙂

Nice, I'll adjust our service 💯 💪

Ooh, very nice 👍

Yeah, it's supercool. The first thing I did this morning integrate it into my service and deploy 😃 it's such a fun working with http4k

I've done the same thing with RunBlocking and coroutines .. what's wrong with this approach?

@Nicola do you have an example? I'd be curious to compare the example above with the equivalent using coroutines. My first thought is that there's nothing inherently wrong, but I expect people would be looking for specific benefits if they're adding a new dependency for something that Java supports out of the box.

The core lines are something like these:

requestsChunks.forEach {
    apiResponses
        .add(CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO>)
            .async {
                mavService.send(it)
            })
}

runBlocking {
    apiResponses
        .awaitAll()
        .flatMap {
            it.toList()
        }
}

Inside "mavService.send" there is an ok http client which calls an external service

@Nicola if I understood the idea by @s4nchez and @dave correctly is to keep the dependencies as small as possible - so no extra dependency for coroutines. Regarding your suggested solution, I don’t understand how you preserve zipkin traces to keep traceability? I thought I have to provide these information as additional context element and then set it anyways in each single coroutine?

@DanielZ I have no zipkin traces .. (to be honest I don't know what they are..) and I don't care about the coroutine dependencies too. I thought coroutines are better than jvm threads so I always prefer them ...

Okay, I understand. In this case it doesn’t solve my problem, since I have to trace all requests. Thank you for your input 😊