Hi Suho, Thanks for your answer. Currently, I haven't any implementation or performance numbers.
Our proposal is independent on the partition of rule structure itself. Thus, it will be compatible with any work on that aspect from your side. We agree a rule partition is a good point, but also that the way to do so can become quite complex as you improve the cost analysis function. We can benefit too from such advances. Our proposal at this moment is just for "sequence of events". Afterwards, we will think about extending it to other cases, involving operations. Of course, in this later case, to make operational sense we won't be able to trigger an event per event, but some kind of "micro window with a report" will have to be applied. Also, at a later iteration we could work on reducing the triggered events with some intelligence and knowledge of the underlying structure. For example, if the next rule depends on a dimension that is partitioned to the same partition and the current rule, then a trigger would not be needed. But the problem here is that this kind of tricks might be dependent on the transport mechanism (fe. Kafka). I would be very grateful if you would help me with at which Siddhi Core classes I should implement the distribution logic. Where are the states stored? Which class does the state handling? Thank you again. Regards, Pablo -- View this message in context: http://wso2-oxygen-tank.10903.n7.nabble.com/PROPOSAL-Distribute-internal-machine-states-tp144849p144902.html Sent from the WSO2 Architecture mailing list archive at Nabble.com. _______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
