Ive noticed something strange when using ktor & making a bunch of calls in quick succession. The last step in the chain involves 3-4 requests being processed in parallel on my backend; and at that point one of the requests fails unexpectedly, ultimately I end up with an EOF exception being thrown (due to timeout I believe). Since the last step is where it fails, I thought Id repeat that until I get to the bottom of it. Problem? It just works seamlessly, and its a lot faster (10-20x) compared to when its part of a chain of calls. Is this common? Im still making the same 3-4 requests in parallel at that point; Im just not doing all the other stuff beforehand. More details in 🧵

This may be a problem in the CIO engine. Can you please file an issue with code samples for the client and the server attached?

Interesting, Ive filed an issue. After creating it, Im honestly not sure what engine the library uses - its created using the

HttpClient {}

block, without any mention of the underlying engine to use. See code here.

Might be related to an issue I ran into a while ago: https://youtrack.jetbrains.com/issue/KTOR-5697 Slightly different but it went away when I switched to the Java engine instead of CIO. Also only happens when doing lots of requests concurrently. I have one project where we run a lot of integration tests with multiple threads that triggers this.

I thought Id switch to the java engine as well to see if and how it affects this! Im doing parallel requests similar to your description, but nowhere near 40k, or even 1k 😅 Would you say that your issue happens when the number is under 100 as well?

Yes, I'm running our tests with about 20 threads and the same Spring context. And all of them are doing http requests using the same client instance.

Gotcha, perhaps Im not crazy after all then 😅 Will run some more tests tomorrow and report back if I find anything worth mentioning!

I think there might be problems if those clients refer to a shared object.

There are no shared objects between the variables. The thing that would strike me is that clinit creates them and a bunch of other variables (and the reference to one of the variables comes from a background thread, not sure if that matters). It would at least explain why lazy fixes it.