javabotdreamreal's title: "Because It's Not Fun Enough | bytecode.news"
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
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?
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
* sa02irc joined #java
GreenResponsethis 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
dreamrealI've never seen Top Gear, no context for that, but I like the idea
dreamrealsonOfRa: hrm, alas, no - infinispan is not my cup of tea :/
sonOfRaDefinitely one of the more "interesting" outages I've had the pleasure to see, but completely stumped on how to fix it :D
dreamrealoutside of cranking up the "bad node" metrics, not sure, if the heartbeat was passing enough
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...
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...
nevetBecause It's Not Fun Enough: why languages fail | Hacker News
javabotdreamreal's title: "Because It's Not Fun Enough: why languages fail | Hacker News"
* metalmaniac joined #java
* yeahitsme2 joined #java
* Cae2 joined #java
* jamezp joined #java
* acidjnk joined #java
* enoq joined #java
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?
enoqmy gutt feeling is no
enoqso spring webflux is still the goto when you to executed a lot of parallel code in one request
enoqexecute*
dreamrealwait what
dreamrealit depends on how the transaction context is propagated, and spring is already virtual thread compatible
dreamrealso my gut feeling is very yes
dreamrealand spring webflux is not the goto unless you have a very 0.2% application
dreamrealand that 0.2% is probably VERY generous to webflux
sonOfRaceterum censeo webflux esse delendam
sonOfRaGod I hate reactive programming.
enoqdreamreal: I'm thinking about something like parallel transactions
enoqfire off 2 transactions in parallel
enoqthen wait until they both complete or roll them all back
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
enoqyou can propagate transaction state using mdc but things might break
dreamrealyeah, 2PC is a drag
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)
dreamrealyour life is going to be SO interesting
enoqwith webflux?
dreamrealwebflux sucks
dreamrealso sure
dreamrealwhy not
sonOfRaIt works well enough, I wouldn't say it sucks
enoqso my impression is that it translates really well to coroutines and then you've got your imperative programming model back
sonOfRaIt's just that reactive programming in general is terrible
enoqI mean, apart from flux
dreamrealI'd say it sucks because reactive programming is terrible
sonOfRafair enough
dreamrealfor a VERY VERY VERY VERY SMALL set of problems it's great
dreamrealMy first response to everyone saying "but that's what I have!" is "you are incorrect"
enoqI'm also somewhat familiar with RxJS and it's terrible, yeah
sonOfRaWe've built some nice scalable stuff with it! Say, the digital tickets for the paris and milano olympics
dreamrealI know this is not true in every case
* five618480339176 joined #java
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?
BombeMy main goal is to avoid creating a separate XYListener for every little thing that I want to trigger.