Community
Participate
Working Groups
When an observable list to a matcher result is created through org.eclipse.viatra.addon.databinding.runtime.api.ViatraObservables.observeMatchesAsList(Matcher), a RuleEngine is created which is never disposed. It should be disposed on the observable's disposal event if it was created solely for this observable instance.
New Gerrit change created: https://git.eclipse.org/r/81809
The proposed patch provides a fix for this issue. I think we should consider deprecating the methods which accept a query engine and enforce the usage of a rule engine. Together with an easy way to create it (RuleEngines.createViatraQueryRuleEngine at the moment), this would make the user aware that this object should be managed by his code. At the very least, we should educate users better (wiki and JavaDoc) about the life cycle of such observables. However, you could also convince me that users who would like to use VIATRA Observables should not have to worry about such issues and having too many rule engines is not a serious problem, as they are not too heavyweight.
Would sharing rule engines across Observable* provide any significant performance benefits?
It would decrease the number of listeners in several places. My guess is that once there are observables in the thousands, the overhead becomes measurable (each model update listener is invoked, then executes SchedulerFactory -> Scheduler -> ScheduedExecution -> IExecutor -> iterate on conflict set). Sharing the rule engine would result in a single iteration on one conflict set.
In that case, can we perhaps use a default "managed" rule engine for each event source (VQ engine), similarly to the managed VQ engine for each model scope?
Yes, managed EVMs might make sense and have come up at least for me several times. However, due to the high degree of configurability, it seemed better to avoid choosing a default configuration. Still, we could have a manager for execution schemas like this: - initialised on a given Query Engine - uses model update listener of engine for scheduling Even in this case you would need to either restrict access to modifying the conflict resolver or risk different applications disrupting each other. A middle ground would be to implement such a manager without making it singleton and the VIATRA Data binding could use an internal instance for observables of the same query engine (since it knows that it is safe to do that). Even simpler, such an implementation could be directly added to VIATRA Data binding and if it seems reusable, moved to EVM core later. I think this last point should be doable in 1.5 timeframe.
Gerrit change https://git.eclipse.org/r/81809 was merged to [master]. Commit: http://git.eclipse.org/c/viatra/org.eclipse.viatra.git/commit/?id=9ff2ef36a1b1d336398300e6fd75da9378f3ab84
Observables created using query engine should no longer leak rule engines.
