ByteCode.News
RSS
SubmitLog in

Community

Chat Logs

Monday, August 10, 2026

  1. * Munnu joined #java
  2. * hwpplayer1 joined #java
  3. * Cae2 joined #java
  4. * pebble joined #java
  5. * acidjnk joined #java
  6. * anomal joined #java
  7. * leppard joined #java
  8. * hwpplayer1 joined #java
  9. * hwpplayer1 joined #java
  10. * WizJin joined #java
  11. * Afroboy joined #java
  12. * hwpplayer1 joined #java
  13. * GreenResponse joined #java
  14. * MikeBux joined #java
  15. * Afroboy joined #java
  16. * Afroboy joined #java
  17. * skum joined #java
  18. * Afroboy joined #java
  19. * Cae2 joined #java
  20. * Afroboy joined #java
  21. dreamrealhttps://bytecode.news/posts/2026/08/because-it-s-not-fun-enough
  22. javabotdreamreal's title: "Because It's Not Fun Enough | bytecode.news"
  23. 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
  24. 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?
  25. 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
  26. * sa02irc joined #java
  27. 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
  28. dreamrealI've never seen Top Gear, no context for that, but I like the idea
  29. dreamrealsonOfRa: hrm, alas, no - infinispan is not my cup of tea :/
  30. sonOfRaDefinitely one of the more "interesting" outages I've had the pleasure to see, but completely stumped on how to fix it :D
  31. dreamrealoutside of cranking up the "bad node" metrics, not sure, if the heartbeat was passing enough
  32. 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...
  33. 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...
  34. dreamrealupvotes appreciated: https://news.ycombinator.com/item?id=49242245
  35. nevetBecause It's Not Fun Enough: why languages fail | Hacker News
  36. javabotdreamreal's title: "Because It's Not Fun Enough: why languages fail | Hacker News"
  37. * metalmaniac joined #java
  38. * yeahitsme2 joined #java
  39. * Cae2 joined #java
  40. * jamezp joined #java
  41. * acidjnk joined #java
  42. * enoq joined #java
  43. 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?
  44. enoqmy gutt feeling is no
  45. enoqso spring webflux is still the goto when you to executed a lot of parallel code in one request
  46. enoqexecute*
  47. dreamrealwait what
  48. dreamrealit depends on how the transaction context is propagated, and spring is already virtual thread compatible
  49. dreamrealso my gut feeling is very yes
  50. dreamrealand spring webflux is not the goto unless you have a very 0.2% application
  51. dreamrealand that 0.2% is probably VERY generous to webflux
  52. sonOfRaceterum censeo webflux esse delendam
  53. sonOfRaGod I hate reactive programming.
  54. enoqdreamreal: I'm thinking about something like parallel transactions
  55. enoqfire off 2 transactions in parallel
  56. enoqthen wait until they both complete or roll them all back
  57. 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
  58. enoqyou can propagate transaction state using mdc but things might break
  59. dreamrealyeah, 2PC is a drag
  60. 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)
  61. dreamrealyour life is going to be SO interesting
  62. enoqwith webflux?
  63. dreamrealwebflux sucks
  64. dreamrealso sure
  65. dreamrealwhy not
  66. sonOfRaIt works well enough, I wouldn't say it sucks
  67. enoqso my impression is that it translates really well to coroutines and then you've got your imperative programming model back
  68. sonOfRaIt's just that reactive programming in general is terrible
  69. enoqI mean, apart from flux
  70. dreamrealI'd say it sucks because reactive programming is terrible
  71. sonOfRafair enough
  72. dreamrealfor a VERY VERY VERY VERY SMALL set of problems it's great
  73. dreamrealMy first response to everyone saying "but that's what I have!" is "you are incorrect"
  74. enoqI'm also somewhat familiar with RxJS and it's terrible, yeah
  75. sonOfRaWe've built some nice scalable stuff with it! Say, the digital tickets for the paris and milano olympics
  76. dreamrealI know this is not true in every case
  77. * five618480339176 joined #java
  78. 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?
  79. BombeMy main goal is to avoid creating a separate XYListener for every little thing that I want to trigger.
  80. ParaI like how its documentation starts (after the "what" explanation) https://github.com/google/guava/wiki/EventBusExplained
  81. nevetEventBusExplained
  82. javabotPara's title: "EventBusExplained 路 google/guava Wiki 路 GitHub"
  83. Para(hint: there's tips for alternatives)
  84. * simon816 joined #java
  85. * pedro_sk8 joined #java
  86. * magla joined #java
  87. * fgarcia_ joined #java
  88. * LtHummus joined #java
  89. * Gaz7051122720067 joined #java
  90. * jiffy__ joined #java
  91. * acidjnk joined #java
  92. * rorx joined #java