"Configuration model x.rules is either empty or cannot be parsed correctly" error

[Dan1001]

Hi,

I'm running OH2.2 snapshot on Ubuntu 14.04. I usually use SublimeText as an editor, editing locally. When I use Visual Studio and the OH extension (also locally) I get the above error when editing rules.

I appreciate a number of people have experienced similar issues with a variety of editors when editing across a Samba networked drive, but a local problem seems unusual, and it was suggested I raise as an issue (see here).

thanks!

Dan

[kaikreuzer]

Could you post a log file with exceptions here?

[Dan1001]

Sure - do you mean just:

2017-08-30 14:04:43.325 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'sonos.rules'
2017-08-30 14:04:43.326 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'sonos.rules' is either empty or cannot be parsed correctly!
2017-08-30 14:04:43.969 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'sonos.rules'

or something else?

Dan

[kaikreuzer]

That is a well known issue when using Samba shares - there simply is a moment in which the file is empty and thus cannot be parsed. So the warning is technically correct.
But your log shows that it is correctly loaded as soon as the content is available. So I expect that everything works, right?

[Dan1001]

The oddity is that this isn't a Samba share - I'm locally editing files on a local drive, and those files aren't shared over the network.

As this is a live system I stopped using Visual Studio when I saw the error - but I'll play with it a little and let you know if I see any real problems.

[Dan1001]

On second thoughts, get a series of errors when I edit an items file:

2017-08-30 14:58:22.347 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'sensors.items'
2017-08-30 14:58:22.353 [WARN ] [ore.common.registry.AbstractRegistry] - org.eclipse.smarthome.core.library.items.NumberItem with key 'CoffeePower' already exists! Failed to add a second with the same UID!
[and so on for each item]

then:

2017-08-30 14:58:22.571 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'sensors.items'

Is this another warning I can happily ignore?

[kaikreuzer]

I'm locally editing files on a local drive

This is weird and I haven't seen this with any other editors - maybe worth to report at https://github.com/openhab/openhab-vscode/issues and have @kubawolanin comment on it.

Is this another warning I can happily ignore?

I am afraid not - this is something that should be looked into.

[Dan1001]

thanks

[Dan1001]

Update on the weirdness: looking again at the logs, it doesn't just give the "failed to add a second" error for the items in that items file; it gives it for every item across all items files. So am I right to think this is definitely an openhab and not a VisualStudio problem?

[Dan1001]

Further update: I just got exactly the same items error when editing with Sublime Text. So not a Visual Studio problem for sure.

[sjsf]

The duplicate items sound like what was fixed by #3641 or #3639 - as you said that you are on a snapshot version, could you please paste the versions of your

org.eclipse.smarthome.model.thing
org.eclipse.smarthome.core.thing

bundles in order to see what exact version you got?

[Dan1001]

Thanks!

Versions are

0.9.0.201708151402 org.eclipse.smarthome.model.thing
0.9.0.201708151402 org.eclipse.smarthome.core.thing

Dan

[sjsf]

From a timing perspective, both PRs should be included in your version. Therefore this needs to be looked into more closely.

Just to be sure we don't miss any clues: Are there any other errors/exceptions in your logs? Maybe the one from #4162?

[Dan1001]

No, no other errors other than those above (with the warning repeated for every single item).

Dan

[mherwege]

@SJKA Probably not related, and I feel we are going away from the original issue filed, but it might give a clue. I noticed the same error on all of my items (both defined in .items files and through PaperUI) when starting or restarting openHAB. I have exactly the same version of ESH running as @Dan1001. It is not consistent though. I tried restarting about 10 times. 7 out of 10, I get the "Failed to add a second with the same UID!" errors. In the other cases, I don't. Everything seems to work though. Also maybe important, I do have a restore on startup strategy for all items from mapDB.
Any logging I can switch on to get an idea when it happens and when it does not?

[Dan1001]

I too have everything restoring on startup from mapDB, but the error occurs well after a restart. I can't find a pattern to when it happens - no more than once every editing session, I would say.

[htreu]

The PR #4163 should fix the duplicate items bug.

Still open here: Configuration model 'sonos.rules' is either empty or cannot be parsed correctly even when edited locally.

[Dan1001]

Cool - do you know when it will go into the snapshot so I can test?

[htreu]

the fix got accepted and merged. the next ESH stable build is planed in the next 12h I guess and the next openHAB snapshot afterwards will be your choice :-)

[Dan1001]

That is awesome - thank you. Out of interest, how come so few people have come across the problem? In other words: why am I special?

[htreu]

The problem originates in a non-deterministic start order of OSGi services. It could happen that the item model was parsed bevor the GenericItemProvider was available. But this does not happen on every startup. And the probability may also depend on your system settings and installed bundles.

[Dan1001]

I've been experiencing it on a system that's been running for hours/days - is it possible I have a different problem? I guess we'll find out when I install the snapshot...

[ThomDietrich]

@kaikreuzer

That is a well known issue when using Samba shares - there simply is a moment in which the file is empty and thus cannot be parsed. So the warning is technically correct.
But your log shows that it is correctly loaded as soon as the content is available. So I expect that everything works, right?

Even though everything technically works, these log messages are "error messages on firth sight" and a lot of users are probably irritated by them. In my opinion they should be dealt with for the sake of UX.
I could imagine they can be easily ignored by adding a "debouncing delay"... wdyt?

[kaikreuzer]

@ThomDietrich My comment is pretty old and has been already proven incorrect in the discussion here. The issue is hence still open and we need to find out what the actual root cause of it is. Ignoring it without knowing why they happen is imho not an option.

[ThomDietrich]

I actually got that, thanks for the clarification.
My main goal was to emphasize, that the warnings should be dealt with rather than just accepting them. Good to know we feel the same way ;)