Hi. :slightly_smiling_face: We are using KTor serv...

# ktor

[Anders Sveen]

Hi. 🙂 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. 🙂

[Robert Jaros]

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]

yep, likely you need <http://Dispatchers.IO|Dispatchers.IO> around some blocking i/o or similar

[Anders Sveen]

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 -> 
   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. 🙂 Is it as easy as adding a coroutine context with Dispatchers.IO around the synclib?

[Anders Sveen]

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? 🙂

Like this?

syncLib.syncMethod(param1) { syncLibContext -> 
    CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO> + ...).launch {
        call.respond(syncLibContext.value)
    }
}

[Robert Jaros]

I would say:

CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO> + ...).launch {
    syncLib.syncMethod(param1) { syncLibContext -> 
        call.respond(syncLibContext.value)
    }
}

[Anders Sveen]

That gives the same compile error though... 😕 'Suspend function should be called...'

[Robert Jaros]

why is this syncMethod taking a callback parameter?

[Robert Jaros]

it looks like async for me

[Anders Sveen]

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<Unit, RuntimeException> { handle ->
            val resultStream = generatorFunc(handle)
            call.respondOutputStream(ContentType.parse("application/json")) {
                jsonHandler.streamObjectsToJson(resultStream, this, receiptCallback, endCallback)
            }
    }

[Robert Jaros]

I think inTransaction method should return a value.

[Robert Jaros]

So you should try something like this:

[Robert Jaros]

val stream = withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
	jdbi.inTransaction<Unit, RuntimeException> { handle ->
         val resultStream = generatorFunc(handle)
         jsonHandler.streamObjectsToJson(resultStream, this, receiptCallback, endCallback)
         resultStream
    }
}
call.respondOutputStream(ContentType.parse("application/json")) {
	stream
}

[Robert Jaros]

I don't know jdbi API, but maybe first run jdbi function with Dispatchers.IO, get the result and next sent it with Ktor call response

[Anders Sveen]

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. 🙂

[Robert Jaros]

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

[Anders Sveen]

Thanks. 🙂 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... 🙂

[Anders Sveen]

So this compiles... And no runBlocking... But I worry that it still blocks stuff in KTor (low comprehension here)... Anyone can tell? 🙂

jdbi.open().use { handle ->
    val resultStream = generatorFunc(handle)
    call.respondOutputStream(ContentType.parse("application/json")) {
        jacksonFactory.createGenerator(this).use { jacksonGenerator ->
            jacksonGenerator.writeStartArray()
            resultStream.forEach {
                jacksonObjectMapper.writeValue(generator, it)
            }
            jacksonGenerator.writeEndArray()
        }
    }
}

[Robert Jaros]

you should be able to put this inside withContext(<http://Dispatchers.IO|Dispatchers.IO>) { ... } to make sure it will not block Ktor