Advanced Join Patterns for the Actor Model Based on CEP Techniques

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.

The paper: The motivation is a problem suitable to be solved via rule systems. It's a bit unclear why the rule system needs to be grafted on top of an actor model.

Actors: Programming with async messages is hard. Message ordering matters, no clear error reporting, no stack traces, distributed state. This is hardware hard, as in bring in formal verification methods hard. To be avoided in favor of a centralized coordinator solution if at all possible.

I wonder if, alternatively, one could use Rx processing over the stream of events.

Motivating example from the paper:

1. Turn on the lights in a room if someone enters, and the ambient light is less than 40lux.

2. Turn off the lights in a room after two minutes without detecting any movement.

3. Send a notification when a window has been open for over an hour.

4. Send a notification if someone presses the doorbell, but only if no notification was already sent in the past 30 seconds.

5. Detect home arrival or leaving based on a particular sequence of messages, and activate the corresponding scene.

6. Send a notification if the combined electricity consumption of the past three weeks is greater than 200 kWh.

7. Send a notification if the boiler fires three Floor Heating Failures and one InternalFailure within the past hour, but only if no notification was sent in the past hour.

It had to be plug and play [non technology savvy users]. The Raspberry PI was unattended and had to re-connect to the internet and re-connect with the device automatically, always. Check data, pull in code updates automatically.

They were distributed geographically, in different time zones, with unstable internet.

Timezones are not easy to work with. I've had nightmares about them.

- [0]: https://github.com/kquick/Thespian

When I write parallel-first code in a fancy language, I find that I can get better absolute performance by just writing plain old single-threaded C. And when my data gets big, it is relatively easy to turn my C-algorithm-using-arrays into a C-algorithm-using-arrays-backed-by-mmap. Mmap is harder to use in every other language I've tried - or comes with additional worries.

And often a single-threaded algorithm is still the way to go, even in a multi-user system, because you can usually let the 'next layer up' multiplex the requests for you, whether it's your web framework or nginx or whatever.

I think that might be the way to make 'fuller use of the multiprocessing capabilities of the processors we have today and the fortunes of RAM'.