ByteCode.News
RSS
SubmitLog in

Community

Chat Logs

Monday, August 10, 2026

  1. dreamrealhttps://bytecode.news/posts/2026/08/because-it-s-not-fun-enough
  2. javabotdreamreal's title: "Because It's Not Fun Enough | bytecode.news"
  3. sonOfRaAny folks around with some in depth experience with jgroups/infinispan? We had a fun outage a while back, caused by ceph saturating the UPI due to misconfigured NUMA affinity, which led to basically all I/O on that node stalling hard. We're running a default jgroups-tcp stack with jdbc-ping instead of mping as discovery. In the end it looked like the I/O was saturated enough that basiaclly all actual writes to the broken node failed, and all of the writes of
  4. sonOfRathat broken node against other nodes also failed. However: Neither the FD_SOCK2 socket got closed to trigger suspicion, nor was the network apparently saturated enough to prevent the FD_ALL3 heartbeats from failing enough times in a row to evict the bad node. Any advice at all on reconfiguring the stack, so if this happens again, our whole cluster doesn't fail?
  5. sonOfRaIn the end, all the other nodes also stalled because after the thread pools writing to the cache filled up, and then the http workers eventually filled up as well
  6. GreenResponsethis languages categorisation resembles former Top Gear鈥檚 host Clarkson walls of good, bad and ugly cars. It鈥檚 just stirring some stupid culture wars about everything
  7. dreamrealI've never seen Top Gear, no context for that, but I like the idea
  8. dreamrealsonOfRa: hrm, alas, no - infinispan is not my cup of tea :/
  9. sonOfRaDefinitely one of the more "interesting" outages I've had the pleasure to see, but completely stumped on how to fix it :D
  10. dreamrealoutside of cranking up the "bad node" metrics, not sure, if the heartbeat was passing enough
  11. sonOfRaBriefly considered doing something via looking at prometheus metrics written by the cluster but thought better of it - those were gone during the outage because the scraper didn't get assigned a http worker to actually scrape metrics...
  12. sonOfRaUnfortunately all the "suspect a node as down" logging is DEBUG gated, would have been nice to actually be able to see at least the chatter from the non-broken nodes if they ever suspected the bad node at any point...
  13. dreamrealupvotes appreciated: https://news.ycombinator.com/item?id=49242245
  14. nevetBecause It's Not Fun Enough: why languages fail | Hacker News
  15. javabotdreamreal's title: "Because It's Not Fun Enough: why languages fail | Hacker News"
  16. enoqdo we know if when structured concurrency hits in the JDK we will be able to do parallel stuff in non-concurrent code like Transactions in Spring WebMVC?
  17. enoqmy gutt feeling is no
  18. enoqso spring webflux is still the goto when you to executed a lot of parallel code in one request
  19. enoqexecute*
  20. dreamrealwait what
  21. dreamrealit depends on how the transaction context is propagated, and spring is already virtual thread compatible
  22. dreamrealso my gut feeling is very yes
  23. dreamrealand spring webflux is not the goto unless you have a very 0.2% application
  24. dreamrealand that 0.2% is probably VERY generous to webflux
  25. sonOfRaceterum censeo webflux esse delendam
  26. sonOfRaGod I hate reactive programming.
  27. enoqdreamreal: I'm thinking about something like parallel transactions
  28. enoqfire off 2 transactions in parallel
  29. enoqthen wait until they both complete or roll them all back
  30. enoqreason I'm asking is because I've watched a talk that included spring transactions not being thread safe since they are bound to thread locals
  31. enoqyou can propagate transaction state using mdc but things might break
  32. dreamrealyeah, 2PC is a drag
  33. enoqI'm working my way up to a BFF and am constantly bumping between webflux and mvc right now due to different constraint (and integration with kotlin coroutines)
  34. dreamrealyour life is going to be SO interesting
  35. enoqwith webflux?
  36. dreamrealwebflux sucks
  37. dreamrealso sure
  38. dreamrealwhy not
  39. sonOfRaIt works well enough, I wouldn't say it sucks
  40. enoqso my impression is that it translates really well to coroutines and then you've got your imperative programming model back
  41. sonOfRaIt's just that reactive programming in general is terrible
  42. enoqI mean, apart from flux
  43. dreamrealI'd say it sucks because reactive programming is terrible
  44. sonOfRafair enough
  45. dreamrealfor a VERY VERY VERY VERY SMALL set of problems it's great
  46. dreamrealMy first response to everyone saying "but that's what I have!" is "you are incorrect"
  47. enoqI'm also somewhat familiar with RxJS and it's terrible, yeah
  48. sonOfRaWe've built some nice scalable stuff with it! Say, the digital tickets for the paris and milano olympics
  49. dreamrealI know this is not true in every case
  50. BombeHmm, I have a project here with a Guava EventBus, and I want to get rid of that, and I started using Project Reactor. Was that a bad idea?
  51. BombeMy main goal is to avoid creating a separate XYListener for every little thing that I want to trigger.
  52. ParaI like how its documentation starts (after the "what" explanation) https://github.com/google/guava/wiki/EventBusExplained
  53. nevetEventBusExplained
  54. javabotPara's title: "EventBusExplained 路 google/guava Wiki 路 GitHub"
  55. Para(hint: there's tips for alternatives)