Fork me on GitHub

Would you like a onyx-local-rt PR for not allowing to add a segment to non-existent task?


Does Onyx "park" idle aggregations? I might have some aggregation window groups that are created by mistake and should disappear eventually, or at least not occupy resources after I log the occasion.


It doesn't really park there but you could use triggers and refinements to cull every now and again


@lucasbradstreet Refinements will clean the group aggregation state but not the group aggregation itself.


Yes, you will still have the key in the group aggregation, though it will have nothing in it


Would it make sense to have some policy to drop them?


BTW, I added an ordering aggregate to my CQRS example. In case commands arrive out of order (according to an offset), they are buffered until it has a contiguous batch to process. Can anyone comment if there's a sane way to do that?


yonatanel: I think so. Could you create an issue?


With the in order processing, we’ve done something similar in the past. The idea was You initialise the window with a starting point (say the known first offset). Then you create some simple aggregations to just add each message to the window state.


The trick is to evict all of the available in-order messages that you emit when you call the trigger


So the trigger grabs all of the in order messages, and emits them somewhere, then the refinement evicts them


Looks pretty similar to what you’re doing but I only gave it a cursory glance


Mine is more complex since the segments are commands that need to be processed in order and change the aggregation internal state. The trigger evicts the already handled commands but leave the internal state as is.


It's gonna get some more behavior such as timeout if we wait to long for a missing segment. I think it can be useful for anyone who also considers actors


Yeah, that’s basically the strategy that we took.


So if there's anything in onyx that guarantees order once I found the order, it could be very nice.


When we land Asynchronous Barrier Snapshotting we will be able to guarantee in order processing depending on the topology