4 ms·
"better alternative to Green threads" Do you have opinions about Java's Project Loom? I'm a simple bear. I have always struggled with the architecture and org
by specialist 6y ago
"better alternative to Green threads"
Do you have opinions about Java's Project Loom?
I'm a simple bear. I have always struggled with the architecture and organization of my async code. Stuff like exception handling, percolating errors up, rational back pressure and retry.
My goal is to rewrite some of my server code using Project Loom, to see how it helps.
"why we don't make fuller use of ... the fortunes of RAM we have now"
I know you mention this as an aside, but I'd appreciate examples.
I've been personally frustrated by teammates using external key/value stores for hot data sets which would trivially fit within RAM. But haven't had ready-made solutions.
One recurring objection, for which I've had no good response, is how to quickly hoist (prime, seed, better term needed here) the RAM of new instances.
Last time this came up, I helped come up with a compromise kludge using Redis. We added a local Redis instance to each web server, had the "master" create regular snapshots, copied that snapshot onto new EC2 instances during boot, used the snapshot to prime its local cache.
It worked pretty good. Though I would have preferred in process, using Redis allowed better inspection and debugging, which was pretty cool. But devops wise, this Rube Goldberg kludge broke most teammate's brains.
Thanks for listening. I keep looking to see if anyone's got a more turnkey solution.
- an_opabinia 6y ago> Do you have opinions about Java's Project Loom? My experience with puniverse/quasar, Loom's predecessor, has been overall positive. There exists a whole actors framework built on top of it. The real problem is how clumsy it is to work with modern Futures code, you have to wrap everything.
- lostcolony 6y ago"I've been personally frustrated by teammates using external key/value stores for hot data sets which would trivially fit within RAM. But haven't had ready-made solutions." You don't need a ready made solution unless you are trying to keep the data consistent, too. If you are, better to use something off the shelf. If you aren't...just deserialize it into whatever local data format makes sense, the same as you'd do reading from an external cache. You basically just have some push/poll mechanism to get data from your data store when updated/at intervals, deserialize it, and now it lives in RAM. The one downside of that is if autoscaling is thrashing instances, it can thrash your data store (though that's true with Redis etc too, depending what is loading data into it; having a caching layer in between DOES decouple that), and also what happens if the data store is unreachable (I've done things like query the rest of the cluster for the data, just via a REST API, because the total amount needed was all of a few megs).