It would be mostly useful for simple windowing jobs, especially those that could be satisfied over an entire topic's partitions with a single peer, or those where the kafka topics are partitioned nicely (pre grouped) and you can use multiple peers

It wouldn't be very useful if you're trying to use output plugins of any kind, but for building windows that could be dynamically queried via onyx peer http query, if would do quite nicely

Main motivation is to bring down resource consumption and operations complexity for simple jobs.

would this runtime mean there’s no need for zookeeper and things like that ?

i think it could be useful when you have small, isolated aggregates you want to keep track of. might work best if there’s a “http server” output plugin, which just serves the current state of the window over http.

@lmergen that's exactly the idea. We already have the window state http server implemented. Initially we'd have it depend on zookeeper, though it would be possible to do it without zookeeper.

This type of thing really could be useful. We were working on using onyx in an appliance environment. This would make it much easier to run

Yeah, definitely a lot of power here.

If anyone has a use case for this in a production environment, drop us a PM. The more input the better on these things.