Hi slightly smiling face We are using KTor server Netty engi

Question

Hi slightly smiling face We are using KTor server Netty engine but seeing quite slow response times Some of them are definitely our own fault but some are usually fast then suddenly end up taking 20 30 seconds suddenly The weird thing is that the front proxy closes the connection on a time out but I can see from the logs that the call completes after the time out My theory The slow requests ends up blocking processing in KTor I see the default for runningLimit is 10 does that mean max 10 parallel taks So if 10 ends up slow any new ones will be queued Any thoughts on increasing the runningLimit number Thanks slightly smiling face

Robert Jaros · Answer

You shouldn t block at all Requests that can t respond in a short time should be run with a different dispatcher And then it s up to you how much threads you give to that dispatcher

mp · Answer

yep likely you need `<http Dispatchers IO|Dispatchers IO>` around some blocking i o or similar

Anders Sveen · Answer

Hjm This ansync stuff is pretty new for me I realize it is probably because I added runBlocking around a respond to make it work inside a sync block How would you guys do something like this ```syncLib syncMethod parm1 syncLibContext gt call respond syncLibContext value ``` This of course gives the Suspend function respond should be called only from a coroutine or another suspend function Any pointers is highly appreciated slightly smiling face Is it as easy as adding a coroutine context with <http Dispatchers IO|Dispatchers IO> around the synclib

Anders Sveen · Answer

Hjm so I am launching a CoroutineScope IO dispatcher and some other stuff like MDC within the syncMethod block and that seems to be compiling Am I on the right track slightly smiling face Like this ```syncLib syncMethod param1 syncLibContext gt CoroutineScope <http Dispatchers IO|Dispatchers IO> + launch call respond syncLibContext value ```

Robert Jaros · Answer

I would say ```CoroutineScope <http Dispatchers IO|Dispatchers IO> + launch syncLib syncMethod param1 syncLibContext gt call respond syncLibContext value ```

Anders Sveen · Answer

That gives the same compile error though confused Suspend function should be called

Robert Jaros · Answer

why is this `syncMethod` taking a callback parameter

Robert Jaros · Answer

it looks like async for me

Anders Sveen · Answer

It might be I m a bit confused The weird thing I am trying to do here is stream a Jdbi result with Jackson streaming API So they are basically Java libs The real thing here some stuff hidden in jsonHandler though is ``` jdbi inTransaction lt Unit RuntimeException gt handle gt val resultStream = generatorFunc handle call respondOutputStream ContentType parse application json jsonHandler streamObjectsToJson resultStream this receiptCallback endCallback ```

Robert Jaros · Answer

I think `inTransaction` method should return a value

Robert Jaros · Answer

So you should try something like this

Robert Jaros · Answer

```val stream = withContext <http Dispatchers IO|Dispatchers IO> jdbi inTransaction lt Unit RuntimeException gt handle gt val resultStream = generatorFunc handle jsonHandler streamObjectsToJson resultStream this receiptCallback endCallback resultStream call respondOutputStream ContentType parse application json stream ```

Robert Jaros · Answer

I don t know jdbi API but maybe first run jdbi function with <http Dispatchers IO|Dispatchers IO> get the result and next sent it with Ktor call response

Anders Sveen · Answer

The transaction needs to stay open that s what the block is fore while the stream is read call respondOutputStream If not the underlying to the Stream JDBC cursor will throw an Exception A bit special but an awesome way to make sure you can handle a lot of searches etc without blowing up your memory consumption slightly smiling face

Robert Jaros · Answer

I m afraid I don t know how to use such api with ktor and coroutines disappointed Perhaps someone else will give you better advice

Anders Sveen · Answer

Thanks slightly smiling face I just realized I will have to wait for the entire result to complete before JDBI closes so you are right it should be around the sync I ll have to dig more slightly smiling face

Anders Sveen · Answer

So this compiles And no runBlocking But I worry that it still blocks stuff in KTor low comprehension here Anyone can tell slightly smiling face ```jdbi open use handle gt val resultStream = generatorFunc handle call respondOutputStream ContentType parse application json jacksonFactory createGenerator this use jacksonGenerator gt jacksonGenerator writeStartArray resultStream forEach jacksonObjectMapper writeValue generator it jacksonGenerator writeEndArray ```

Robert Jaros · Answer

you should be able to put this inside `withContext <http Dispatchers IO|Dispatchers IO> ` to make sure it will not block Ktor