Why is that nobody ever talks about dropwizard and...

# server

[Mani]

Why is that nobody ever talks about dropwizard and kotlin together, am I missing something?

[Shawn]

hi, person that uses dropwizard and kotlin together here

[Shawn]

what do you expect to find? DW is a good Java framework that you can use from Kotlin, but there’s nothing about it that’s especially suited for or against Kotlin

[Shawn]

I don’t know much about the Spring Boot extensions for kotlin but I’m unsure what a similar library for dropwizard would look like

[Shawn]

and it’s not like there’s ever going to be a coroutine-ified version of DropWizard - that would require quite an overhaul to solve problems that are already dealt with in a more Java way

[Shawn]

at that point, why not just use Ktor, Vert.x, etc

[Mani]

at which point exactly? In terms of some benchmarks etc..,

[Shawn]

in terms of what the problem you’re looking to solve is

[Mani]

Lets say we have 6-7 different applications running on dropwizard and due to the heavy scale.. our api's and latencies are becoming a bottleneck. So how ktor etc.. will solve the problem

[Shawn]

Is there some aspect intrinsic to Kotlin that would solve the problem?

[fred.deschenes]

I've used Kotlin with Dropwizard a bunch, but apart from the code being written in Kotlin there's no real advantage versus using Java

[Shawn]

What you originally asked about was discussion on Kotlin being used with DropWizard, and I’m trying to say that you don’t need discussion on the combination to use it - support for DropWizard and Kotlin looks almost identical to support for DropWizard and Java

[Shawn]

so does performance and ergonomics for the most part

[Mani]

coroutines? in case of db calls. let me explain the exact problem we've started facing recently. We have a bunch of api calls in a service that are slogging.. we haven't tried with coroutines yet.. will it help? because there are almost 5k - 10k db calls in these api calls

[Shawn]

I mean, DropWizard provides JDBI, but it’s older and doesn’t come with the Jackson Kotlin extension so you can use data classes - in the projects I’ve worked on, we bring in JDBI3 and the mapper

[Mani]

same here..

[Shawn]

but the rest of the code can’t make suspend calls

[Mani]

and that actually sucks.. your thoughts?

[Mani]

So you mean to say that using coroutines will not help much in my scenario since it is using JDBI3 internally?

[fred.deschenes]

Dropwizard does support JDBI3, but coroutines won't help you as long as JDBC is synchronous

[Shawn]

right, that’s what I’m trying to say

[Mani]

Thanks for your time guys 🙂

[fred.deschenes]

no problem, if you have more questions feel free to poke me directly (or just post to #server again)

[fred.deschenes]

and since I'm waiting for Docker to finish building, you might want to look at Vert-x if you absolutely need to have everything async and Kotlin friendly (it has its own async mysql/postgres drivers), but it's a lot different than working with Dropwizard/Spring

[fred.deschenes]

and the next Spring boot release will supposedly have much better Kotlin/coroutines support

[tddmonkey]

Another DW/Kotlin user here

[Mani]

Our entire core is inherited using Dropwizard template. There are more than 10 different huge applications based on it. I never thought we'll get to this problem at scale. But before I start doing something, I want to convince that the server framework change will be more beneficial.

[Mani]

Coming from a python background, I couldn't judge java applications well.

[Mani]

However, my major goal was to refactor that 1-2 services I am accountable for. As the latencies became a headache. Confused whether to attack it from the DB side or the server side by introducing coroutines etc..,

[fred.deschenes]

but is your bottleneck your actual DB or your access to said DB in Dropwizard?

[Mani]

access to db in dropwizard is what I am suspecting since the DB's biggest table is only 30-40 million rows and with useful indexes etc..,

[Mani]

Again this is an assumption, I can't tell the exact problem

[tddmonkey]

Don’t assume. Measure.

[Mani]

You're right. Started doing it. I can tell the DB latencies and API latencies. With this information, how do I decide which one should I tackle?

[Mani]

Should I do DB partitioning or writing coroutines

[Mani]

That's the reason I wanted to know if coroutines in DW context especially when using JDBI is any useful

[fred.deschenes]

definitely work on the DB, writing coroutines won't give you better performance there (might even make it worse by having multiple queries run in parallel where they would have been sequential before, etc)

[Mani]

Sure, I will update this thread if its improved 👍 So, can I safely take this point from this thread that using coroutines in the context of JDBI will not help much as the JDBC is synchronous

[Mani]

Please correct me if I am wrong since its 2:30 AM here and my statements might not make sense

[fred.deschenes]

well it's 5 PM on a Friday here so I can't guarantee to make more sense, but yeah that seems right 😛

[tddmonkey]

I’m gonna generalise quite a lot, but if you’re using a typical RDBMS, i.e. blocking IO, unless you’ve done something stupid in your app - switching to coroutines or some other flavour of then month isn’t going to help you with latency

[tddmonkey]

What you’re looking at is more than likely a resource contention issue, but without more information we won’t be able to help you

[tddmonkey]

An easy way to figure out if its your actual DB or not - throw more app server at the problem - does your latency go down or not? If it does, it’s not your DB. If it doesn’t, it’s not your app

[Mani]

which boils down to increase more number of pods and check. got it 👍

[tddmonkey]

It helps if you have a very thorough understanding about how each of the parts in your architecture manage resources. Your DB will have a threadpool and queue. I assume you have a connection pool in the DW app too, and a queue. Then you’ll have the thread pool for your DW worker threads and a queue for requests waiting to be served. There’s undoubtedly more that I’ve forgotten (it’s lateish here). You need to understand what happens to your requests as it goes through all of these, and which, if any, is the bottleneck

[tddmonkey]

Alternatively, use a DB tech that scales horizontally and some of these worries can go away 😄

[Henry]

Bit late to this party but there are async db drivers in development which may be of interest if you decide that blocking db io is causing you problems https://github.com/rdbc-io/rdbc

[Mani]

Thanks @Henry I will check this