Community
Chat Logs
Monday, July 13, 2026
- enoqso I asked about virtual threads (spring) and parallel http requests a couple days ago; turns out by default it's not parallelized (which is what I expected) https://dpaste.com/EXBWBMSAN
- enoqwhen I curl the endpoint, it waits for 20s
- enoqwhat's the recommended way to deal with that? wrap in CompletableFuture.supplyAsync?
- enoq(not 100% sure if that approach loses ThreadLocal context)
- enoqthere's also @Async btw
- Parahuh, my firewall says dpaste is a dangerous website
- enoq~pastebin list options
- javabotenoq, what does that even *mean*?
- enoq~pastebin
- javabotPlease paste your code and any errors online. For runnable classes, try https://ideone.com/ . For general code and errors, use https://gist.github.com or https://dpaste.org/
- nevetDiscover gists
- enoqdpaste.org is down
- enoqhttps://gist.github.com/BernhardPosselt/a5638b26987519fdb60b2fdd414f5443
- nevetProductController.kt
- ParaSo, it does exactly what it should?
- enoqright, I think we had another misunderstanding back then
- enoqvirtual threads don't parallelize IO in the same thread
- ParaI mean... you've literally written "wait 10 seconds, then wait 10 seconds" :)
- enoqsince I'll be aggregating a lot of different rest endpoints, this makes me wonder if I should go reactive and maybe Kotlin coroutines
- ParaThat sounds like quite a leap to conclusion. You've written synchronous code, that will not magically turn into asynchronous.
- enoqspring.threads.virtual.enabled=true btw
- enoqso it will spin off a virtual thread per request
- enoqso it should be async, just not parallel
- ParaYou're solving the wrong problem. You need to change your programming pattern if you want async/parallel execution.
- enoqright, so this is how I understand it you could do it using servlet tech https://gist.github.com/BernhardPosselt/a5638b26987519fdb60b2fdd414f5443
- nevetProductController.kt
- enoqbasically use CompletableFuture.supplyAsync
- enoqjust not 100% sure if this makes sense
- ParaI don't see how "servlet tech" relates to this at all.
- ParaBut yeah, that's what futures are for.
- enoqservlet as in: not reactive style
- dreamrealenoq: did you turn on virtual threads, and you're seeing *subsequent* invocation?
- enoqI did turn it on, yes
- enoqThread.currentThread().isVirtual() is true
- enoqand they're happening one after another
- dreamrealokay, so let me make sure what's being described: you have AN ENDPOINT, and you're calling it twice, AND it's executing sequentially such that a 10s call is taking 2(10)s, not 10s twice
- dreamrealyou would expect *some* deviation (the time between the "two calls" being started plus a slight deviation for wire transfer time) but those would be pretty small
- enoqI tried to simulate 2 REST endpoints that each take 10s to respond; I want both endpoints to be called in parallel to reduce it from 20s to 10s; later on I'll need to aggregate data from various different services
- enoqif I used Thread.sleep() wrong, let me know
- dreamrealenoq: You shouldn't see sequential behavior from those servlets *even without* virtual threads
- dreamrealsomething else is going on
- enoqI'm calling the /testwait endpoint btw
- enoqfrom my understanding, Thread.sleep in a virtual thread should suspend, correct?
- dreamrealshould suspend THAT THREAD, yes
- dreamrealbut even without virtual threads you shouldn't be seeing one-after-the-other execution
- dreamrealOH
- dreamrealtestwait() is what's blocking, yeah?
- enoqyes
- dreamrealthose ARE sequential for that thread
- dreamrealyou're not executing two calls at the same time
- enoqright, that's what I was trying to communicate, we probably talked by each other
- dreamrealno worries, I'm in a meeting and attention is spread
- dreamrealso this behavior is *correct* for that code
- enoqI don't care too much about being able to serve 100k requests at once, I'm more interested in cutting down on sequential async calls
- dreamrealyou run one, then you run the other: 10s twice. That's correct and expected.
- dreamrealYou're not running those calls at the same time.
- dreamrealYour *code* doesn't run them at the same time.
- dreamrealcreate a list of completion results, then resolve them.
- enoqright, so would you still stick with servlet if that was the main thing your application did and sprinkle in CompletableFutures?
- enoqmy guess is that many requests can't be parallel because they'll depend on previous requests, but there might a good chunk that could
- dreamrealyeah, you're literally needing to spread out the calls, this is where you actually DO get to multiplex requests
- dreamrealIt's not DIFFICULT: create a set of requests and start them, then collect the results
- sambalala -+\
- dreamrealI actually disagree
- ernimril^~!
- dreamrealno, no, you *!@
- dreamrealThou offendsth me
- NeXeNconcurrency != parallel
- NeXeNenoq: and don't fall into the forkjoinpool trap. always lean on your StructuredTaskScope and ExecutorService https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html and https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/ExecutorService.html btw that's loom docs. don't try and use a spliterator or something or you'll end up waiting 10 seconds blocking
- NeXeNthe rest of the world
- javabotNeXeN's titles: "StructuredTaskScope (Java SE 25 & JDK 25 [build 1])" | "ExecutorService (Java SE 25 & JDK 25 [build 1])"
- nevethttps://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html "StructuredTaskScope (Java SE 25 & JDK 25 [build 1])" || https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/ExecutorService.html "ExecutorService (Java SE 25 & JDK 25 [build 1])"