* mwnaylor left #java (ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.2))
* johnjay joined #java
* Betal joined #java
* Anaphaxaway joined #java
* GreenResponse joined #java
* metalmaniac joined #java
* jbosmans joined #java
* jamezp joined #java
* hwpplayer1 joined #java
* RootSipher joined #java
* RootSipher left #java (WeeChat 4.9.2)
* enoq joined #java
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
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
* MikeBux joined #java
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
* jonp` joined #java
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