ByteCode.News
Submit RSS Atom Sign in

Back to the channels

#java

  1. enoq so 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
  2. enoq when I curl the endpoint, it waits for 20s
  3. enoq what's the recommended way to deal with that? wrap in CompletableFuture.supplyAsync?
  4. enoq (not 100% sure if that approach loses ThreadLocal context)
  5. enoq there's also @Async btw
  6. Para huh, my firewall says dpaste is a dangerous website
  7. enoq ~pastebin list options
  8. javabot enoq, what does that even *mean*?
  9. enoq ~pastebin
  10. javabot Please 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/
  11. nevet Discover gists
  12. enoq dpaste.org is down
  13. enoq https://gist.github.com/BernhardPosselt/a5638b26987519fdb60b2fdd414f5443
  14. nevet ProductController.kt
  15. Para So, it does exactly what it should?
  16. enoq right, I think we had another misunderstanding back then
  17. enoq virtual threads don't parallelize IO in the same thread
  18. Para I mean... you've literally written "wait 10 seconds, then wait 10 seconds" :)
  19. enoq since I'll be aggregating a lot of different rest endpoints, this makes me wonder if I should go reactive and maybe Kotlin coroutines
  20. Para That sounds like quite a leap to conclusion. You've written synchronous code, that will not magically turn into asynchronous.
  21. enoq spring.threads.virtual.enabled=true btw
  22. enoq so it will spin off a virtual thread per request
  23. enoq so it should be async, just not parallel
  24. Para You're solving the wrong problem. You need to change your programming pattern if you want async/parallel execution.
  25. enoq right, so this is how I understand it you could do it using servlet tech https://gist.github.com/BernhardPosselt/a5638b26987519fdb60b2fdd414f5443
  26. nevet ProductController.kt
  27. enoq basically use CompletableFuture.supplyAsync
  28. enoq just not 100% sure if this makes sense
  29. Para I don't see how "servlet tech" relates to this at all.
  30. Para But yeah, that's what futures are for.
  31. enoq servlet as in: not reactive style
  32. dreamreal enoq: did you turn on virtual threads, and you're seeing *subsequent* invocation?
  33. enoq I did turn it on, yes
  34. enoq Thread.currentThread().isVirtual() is true
  35. enoq and they're happening one after another
  36. dreamreal okay, 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
  37. dreamreal you 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
  38. enoq I 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
  39. enoq if I used Thread.sleep() wrong, let me know
  40. dreamreal enoq: You shouldn't see sequential behavior from those servlets *even without* virtual threads
  41. dreamreal something else is going on
  42. enoq I'm calling the /testwait endpoint btw
  43. enoq from my understanding, Thread.sleep in a virtual thread should suspend, correct?
  44. dreamreal should suspend THAT THREAD, yes
  45. dreamreal but even without virtual threads you shouldn't be seeing one-after-the-other execution
  46. dreamreal OH
  47. dreamreal testwait() is what's blocking, yeah?
  48. enoq yes
  49. dreamreal those ARE sequential for that thread
  50. dreamreal you're not executing two calls at the same time
  51. enoq right, that's what I was trying to communicate, we probably talked by each other
  52. dreamreal no worries, I'm in a meeting and attention is spread
  53. dreamreal so this behavior is *correct* for that code
  54. enoq I 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
  55. dreamreal you run one, then you run the other: 10s twice. That's correct and expected.
  56. dreamreal You're not running those calls at the same time.
  57. dreamreal Your *code* doesn't run them at the same time.
  58. dreamreal create a list of completion results, then resolve them.
  59. enoq right, so would you still stick with servlet if that was the main thing your application did and sprinkle in CompletableFutures?
  60. enoq my guess is that many requests can't be parallel because they'll depend on previous requests, but there might a good chunk that could
  61. dreamreal yeah, you're literally needing to spread out the calls, this is where you actually DO get to multiplex requests
  62. dreamreal It's not DIFFICULT: create a set of requests and start them, then collect the results
  63. sambalala -+\
  64. dreamreal I actually disagree
  65. ernimril ^~!
  66. dreamreal no, no, you *!@
  67. dreamreal Thou offendsth me
  68. NeXeN concurrency != parallel
  69. NeXeN enoq: 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
  70. NeXeN the rest of the world
  71. javabot NeXeN's titles: "StructuredTaskScope (Java SE 25 & JDK 25 [build 1])" | "ExecutorService (Java SE 25 & JDK 25 [build 1])"
  72. nevet https://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])"