I have installed a brand new OH on my Raspi 3B+ with openhabian 1.5 and OH 2.5.3 stable.
However, I get some errors I would like to solve step by step.
For some I don’t have a clue where to look for an error. Sometimes ther is an indication to check line xx and column yy. This helps a bit though even without the rule’e name.
How about these kind of errors:
2020-04-07 16:33:04.630 [ERROR] [ersey.server.ServerRuntime$Responder] - An I/O error has occurred while writing a response message entity to the container output stream.
org.glassfish.jersey.server.internal.process.MappableException: org.eclipse.jetty.io.EofException
at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:92) ~[?:?]
at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) ~[bundleFile:?]
at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1130) ~[bundleFile:?]
at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:711) [bundleFile:?]
at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:444) [bundleFile:?]
at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:434) [bundleFile:?]
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:329) [bundleFile:?]
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [bundleFile:?]
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [bundleFile:?]
at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [bundleFile:?]
at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [bundleFile:?]
at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [bundleFile:?]
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) [bundleFile:?]
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) [bundleFile:?]
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) [bundleFile:?]
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473) [bundleFile:?]
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) [bundleFile:?]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) [bundleFile:?]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) [bundleFile:?]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) [bundleFile:?]
at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76) [bundleFile:?]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:852) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:544) [bundleFile:9.4.20.v20190813]
bundleFIle:? Does not really help.
and
bundleFile:9.4.20.v20190813
does not show up when checking karaf:
bundle:list | grep 9.4.20.v20190813
Any suggestion how to find out where to look for would be greatly appreciated.
Thanks for the quick response.
So how to perform a refresh?
I usually remove the rules when shutting down and move them back into place 10 min after system started.
I thought approx 60 min after system started OH should be settled!=´?
Oh, stupid me
Thanks.
That might be possible that I have a Paper UI or such open.
I am just wondering why there is no reference to the binding.
(no offense) This would make thing easier for rookies like me.
2020-04-08 07:25:18.055 [WARN ] [pse.smarthome.core.items.GenericItem] - failed notifying listener 'org.eclipse.smarthome.core.persistence.internal.PersistenceManagerImpl@1bac17e' a$
java.lang.IndexOutOfBoundsException: null
at java.nio.Buffer.checkIndex(Buffer.java:546) ~[?:1.8.0_222]
at java.nio.HeapByteBuffer.getLong(HeapByteBuffer.java:416) ~[?:1.8.0_222]
at org.mapdb.DataInput2.readLong(DataInput2.java:104) ~[?:?]
at org.openhab.persistence.mapdb.internal.MapDBitemSerializer.deserialize(MapDBitemSerializer.java:85) ~[?:?]
at org.openhab.persistence.mapdb.internal.MapDBitemSerializer.deserialize(MapDBitemSerializer.java:1) ~[?:?]
at org.mapdb.BTreeMap$NodeSerializer.deserialize(BTreeMap.java:449) ~[?:?]
at org.mapdb.BTreeMap$NodeSerializer.deserialize(BTreeMap.java:288) ~[?:?]
at org.mapdb.Store.deserialize(Store.java:297) ~[?:?]
at org.mapdb.StoreDirect.get2(StoreDirect.java:486) ~[?:?]
at org.mapdb.StoreWAL.get2(StoreWAL.java:336) ~[?:?]
at org.mapdb.StoreWAL.get(StoreWAL.java:320) ~[?:?]
at org.mapdb.Caches$HashTable.get(Caches.java:246) ~[?:?]
at org.mapdb.EngineWrapper.get(EngineWrapper.java:58) ~[?:?]
at org.mapdb.BTreeMap.put2(BTreeMap.java:677) ~[?:?]
at org.mapdb.BTreeMap.put(BTreeMap.java:643) ~[?:?]
at org.openhab.persistence.mapdb.internal.MapDBPersistenceService.store(MapDBPersistenceService.java:165) ~[?:?]
at org.openhab.core.persistence.internal.PersistenceServiceDelegate.store(PersistenceServiceDelegate.java:59) ~[?:?]
at org.eclipse.smarthome.core.persistence.internal.PersistenceManagerImpl.handleStateEvent(PersistenceManagerImpl.java:137) ~[?:?]
at org.eclipse.smarthome.core.persistence.internal.PersistenceManagerImpl.stateChanged(PersistenceManagerImpl.java:437) ~[?:?]
at org.eclipse.smarthome.core.items.GenericItem$1.run(GenericItem.java:261) [bundleFile:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
I used to have persistence issues before the fresh install as well and though, that I messed up my system too much.
However, this is still happening (although I don’t know if it’s the same issue as before).
I assume there is an item still null which cannot be stored in mapdb. But which?
Because I have possibly many items on null because of the brand new start (including persistence),.
Is this an indicator to the item? PersistenceManagerImpl@1bac17e
No, I think that is a ref to a service scheduled job (along the “everyChange” lines of something listening for Item events.
The log includes magic words mapdb and genericItem, so I reckon you’re on the right trail.
Depending what you mean … a selected Item state NULL is absolutely normal, persistence service knows exactly how to deal with that - by not persisting it!. But it will not produce any error.
null in terms of an Item not existing, I’m not quite so sure.
I do not think there is any problem at all if you include Item names that do not exist in your xxx.persist file, even if you specify restoreOnStartup for them.
I do not think there is any problem at all if you include Item names that have never yet had any data persisted in your xxx.persist file, even if you specify restoreOnStartup for them.
I would speculate the exact opposite problem. Are you persisting everything “lazily”? Is there something like a String Item holding monster sized data - a webpage scrape, or image code, or suchlike?
What has been noted to mess up some databases is changing an Item type e.g. Number to String, after it has started persisting. I’ve not heard of that being a problem for mapdb though.
Luckily, because it is mapdb, you do have the option to delete the whole db without losing much in the way of historical records.
Same would be effective if there is some weird existing corruption in the db itself.
I think I would review my mapdb.persist, make sure it looked what I wanted.
Uninstall mapdb
Delete the whole /userdata/persistence/mapdb/ folder and contents.
Delete /conf/services/mapdb.cfg file
Reinstall mapdb and let it start afresh with clean db, should pick up old mapdb.persist.
Thank you for your thorough response.
I am glad to hear that even very experienced guys like you struggle with the one or other issue
The only large string is the response from my car (about 20 lines of json response)
Is that too much?
That’s exactly the issue I have experienced on sql, maria and sqlite which cost me a lot of hair
Will do - thank you.
My mapdb only has one line (is this an issue? I never experienced issues with this yet):
Maybe with Location items which cannot be persisted anyway!? * : strategy = everyChange, restoreOnStartup
Shouldn’t be any bother, I don’t know if mapdb has a limit but it is likely way bigger than that.
That is a very valid point, I do not know how gracefully the essentially 1.x persistence service mapdb deals with an Item type not invented until 2.0
It certainly messes up with other db.
Sounds like a likely culprit.
I’ve never stored that much in mapdb - occupation timestamps and the like. Prefer to write rules that deal sensibly with NULL after startup as “unknown-yet”, to blanket restores.
Thinking on it, I made quite a few custom icon sets as well, featuring a question mark as the default image, to prevent misleading UI icons for NULL.
That was (most likely) the issue.
After changing the mapdb in such way, that only other items than Locations will be taken into account I did not see this error anymore: failed notifying listener
Thanks a lot for guiding me in the right direction!
