<@UAB798V97> Mainly there should be no problem, bu...

# http4k

[dave]

@DALDEI Mainly there should be no problem, but there are a couple of things to consider:
1. You might want to plug in one of the async supporting HTTP clients instead of the blocking ones - the API here is callback based.
2. Anything that relies on threads to propagate (ZipkinTraces mainly) will also require manual transfer between Coroutine contexts. Resilience4j support will be compromised because that is also thread-based.
For any of this stuff, if you could feed back any utility code for acheiving the above (even via just a Gist) that would be awesome, as these are a couple of the currently untackled items remaining on the Coroutine support work.

[DALDEI]

Thank you. THis has me thinking a bit. Im not particularly interested in 'async io' -- as a design principle -- in this case. Rather 'what would happen' if http4k was used in the context of a coroutine-supporting application. In the use case pondered, its perfectly fine for threads to 'block' -- although its desirable to know upfront when that would (potentially) occur so the co-routines can be dispatched to an appropriate context/thread-pool prior to calling known-blockable apis.
In the 2 cases you mention (resilence4j and zipkintraces) -- the only thing I can think of (without studying their code) is reliance on thread local storage or in general assumptions about thread/state persistance. IFF the calls 'into' and 'out of' http4k are single threaded -- but between calls may change threads -- do you know offhand of cases where thread-locality is assumed that spans single request/responses ? I.e. on the client side, where its assumed that all calls occur from the same thread, and on the server side that assume all callbacks are dispatched to the same thread ?
This could occur, for example, if TLS is used to maintain state that outlives a single request/response.
historically Ive seen this in cases where a "Connection" object holds the state, and concurrency is defined wrt the connection ( i.e. do not use the same connection on 2 threads concurrently). -- Its conceivable that implementations store 'connection state' or similar in TLS instead where the rule would be 'Do not run on 2 threads concurrently OR sequentially'
The later can be managed by (fairly new) coroutine ThreadLocal support -- providing one knows what TLS variables to manage 🙂 -- which could be difficult or impossible without 'owning' the code using the TLS. But if the only (known) concerns are concurrency/synchronous related (not which thread but rather 'single threaded' - per request) then I would infer that using http4k in a co-routine enabled application would be no different then any other 3rd party java/JVM application that was not doing anything 'fancy' wrt threading.
This woudl imply that one could 'build on top of' http4k whatever async model one wishes using traditional thread-pool/futures/concurrency designs without major problems.

[dave]

Regarding zipkin, we store the traces in a TL to allow them to travel seamlessly to any client calls. For R4J, the underlying lib is implemented explicly in terms of threads and callables IIRC so would require explicit conversion work. Due to the immutable request/response model, we are pretty safe from object mutation (excerpt streams) - so yes I think your assertion is pretty accurate.

[dave]

For the TLS type stuff, I expect "sharing" of this would be handled by the server backend (undertow is best at this stuff IMHO) - we'd probably fall back on a RequestContext in the first instance if we didn't want to reimplement Request, although we have extended with RoutedRequest and simply used delegation to achieve a similar effect without the contexts.