eclipse-archived / smarthome

Eclipse SmartHome™ project
https://www.eclipse.org/smarthome/
Eclipse Public License 2.0
865 stars 782 forks source link

ModelRepository might lead to timing issues #629

Closed kaikreuzer closed 8 years ago

kaikreuzer commented 8 years ago

migrated from Bugzilla #427087 status NEW severity normal in component DSL for --- Reported in version unspecified on platform All Assigned to: Project Inbox

On 2014-01-31 02:57:15 -0500, Oliver Libutzki wrote:

The ModelRepository is responsible for managing the ResourceSet which includes the model files (items, rules,...).

Every time the FolderObserver detects a new or modified model file, the ModelRepository in notified.

The ModelRepository notifies its listeners after updating its underlying ResourceSet. Unfortunately this is done in a per-file manner which might lead to a lot of problems.

Example at runtime startup: A rules file is reas. The RulesJvmModelInferrer tries to initializes the items by using hte ItemRegistry. Unfortunately the items-Files have not been registered and therefore they are not provided by the ItemRegistry.

General example: A user adds an item and a rule which refers the item. If the rule is loaded earlier, the reference to the item cannot be resolved.

On 2014-01-31 03:05:35 -0500, Oliver Libutzki wrote:

After fixing this we hopefully do not need this code in org.eclipse.smarthome.model.rule.internal.engine.RuleEngine anymore: if(e.getCause() instanceof ItemNotFoundException || e.getCause().getMessage().contains("cannot be resolved to an item or type")) { // we do not seem to have all required items in place yet // so we keep the rule in the list and try it again later }

On 2014-02-03 02:39:37 -0500, Kai Kreuzer wrote:

Thanks, this is a good observation which might explain many startup problems that users have described. What would be your suggestion to solve this issue? Changing the folderobserver to do "bulk" loading?

On 2014-02-06 03:21:04 -0500, Oliver Libutzki wrote:

At least the FolderObserver has to collect some change information in order to update the ResourceSet "transactionally". A complete rebuild is an option, too.

Additionally I noticed the following issue: After reloading a rules-resource the startup rules of this resource are executed. Is this the expected behaviour?

On 2014-02-07 06:54:06 -0500, Kai Kreuzer wrote:

Additionally I noticed the following issue: After reloading a rules-resource the startup rules of this resource are executed. Is this the expected behaviour?

Yes, this is expected at the moment as these rules are considered to be a "run once" rule - i.e. the first time they are loaded to the repo. I agree that the name "startup" rule does not reflect this and so it might be a good idea to change this behavior.

Please also note https://bugs.eclipse.org/bugs/show_bug.cgi?id=423516, which should introduce a mechanism to determine when the runtime has been fully started - so once this is in place, the startup rules could be executed only then and many of your described problems could be solved by this as well.

kaikreuzer commented 8 years ago

Closing this as there is no real bug. It is rather a matter of doing a proper startup management in products build with ESH.