Back to the channels

#java

11:20 dreamreal https://bytecode.news/posts/2026/08/because-it-s-not-fun-enough
11:20 javabot dreamreal's title: "Because It's Not Fun Enough | bytecode.news"
11:29 sonOfRa Any 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
11:29 sonOfRa that 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?
11:30 sonOfRa In 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
11:32 GreenResponse this languages categorisation resembles former Top Gear’s host Clarkson walls of good, bad and ugly cars. It’s just stirring some stupid culture wars about everything
11:33 dreamreal I've never seen Top Gear, no context for that, but I like the idea
11:33 dreamreal sonOfRa: hrm, alas, no - infinispan is not my cup of tea :/
11:33 sonOfRa Definitely one of the more "interesting" outages I've had the pleasure to see, but completely stumped on how to fix it :D
11:34 dreamreal outside of cranking up the "bad node" metrics, not sure, if the heartbeat was passing enough
11:36 sonOfRa Briefly 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...
11:37 sonOfRa Unfortunately 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...
11:38 dreamreal upvotes appreciated: https://news.ycombinator.com/item?id=49242245
11:38 nevet Because It's Not Fun Enough: why languages fail | Hacker News
11:38 javabot dreamreal's title: "Because It's Not Fun Enough: why languages fail | Hacker News"
14:37 enoq do 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?
14:38 enoq my gutt feeling is no
14:38 enoq so spring webflux is still the goto when you to executed a lot of parallel code in one request
14:38 enoq execute*
14:41 dreamreal wait what
14:41 dreamreal it depends on how the transaction context is propagated, and spring is already virtual thread compatible
14:41 dreamreal so my gut feeling is very yes
14:44 dreamreal and spring webflux is not the goto unless you have a very 0.2% application
14:44 dreamreal and that 0.2% is probably VERY generous to webflux
14:45 sonOfRa ceterum censeo webflux esse delendam
14:45 sonOfRa God I hate reactive programming.
15:24 enoq dreamreal: I'm thinking about something like parallel transactions
15:24 enoq fire off 2 transactions in parallel
15:24 enoq then wait until they both complete or roll them all back
15:26 enoq reason 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
15:26 enoq you can propagate transaction state using mdc but things might break
15:28 dreamreal yeah, 2PC is a drag
15:32 enoq I'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)
15:35 dreamreal your life is going to be SO interesting
15:36 enoq with webflux?
15:36 dreamreal webflux sucks
15:36 dreamreal so sure
15:36 dreamreal why not
15:36 sonOfRa It works well enough, I wouldn't say it sucks
15:36 enoq so my impression is that it translates really well to coroutines and then you've got your imperative programming model back
15:36 sonOfRa It's just that reactive programming in general is terrible
15:37 enoq I mean, apart from flux
15:37 dreamreal I'd say it sucks because reactive programming is terrible
15:37 sonOfRa fair enough
15:37 dreamreal for a VERY VERY VERY VERY SMALL set of problems it's great
15:38 dreamreal My first response to everyone saying "but that's what I have!" is "you are incorrect"
15:38 enoq I'm also somewhat familiar with RxJS and it's terrible, yeah
15:38 sonOfRa We've built some nice scalable stuff with it! Say, the digital tickets for the paris and milano olympics
15:38 dreamreal I know this is not true in every case
15:51 Bombe Hmm, 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?
15:52 Bombe My main goal is to avoid creating a separate XYListener for every little thing that I want to trigger.
16:11 Para I like how its documentation starts (after the "what" explanation) https://github.com/google/guava/wiki/EventBusExplained
16:11 nevet EventBusExplained
16:11 javabot Para's title: "EventBusExplained · google/guava Wiki · GitHub"
16:11 Para (hint: there's tips for alternatives)