Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Digitalstrom] Bugfixes/Improvements #8372

Merged
merged 4 commits into from
Aug 31, 2020
Merged

[Digitalstrom] Bugfixes/Improvements #8372

merged 4 commits into from
Aug 31, 2020

Conversation

alexf2015
Copy link
Contributor

This PR addresses several issues/probems:

  1. This fixes issue [digitalstrom] NPE due to race condition #8214
  2. There was no specific handling of SSLHandshakeExecptions, which resulted in a default handling a lots of stacktraces printed to the logs
  3. The default connection error handling was faulty, because the bridge was not set to "offline"
  4. There was some kind of "loop" in the reconnect process which resulted in stack overflows.
  5. Sometimes scene calls get "lost" which ends up in scenes being not updated anymore. Fix: Any scene activation will now be sent to the core even if the status in the binding is already "active".

@alexf2015
added specific error handling for SSLHandshakeExecptions
2eac5d9 
code cosmetics
logging

Signed-off-by: Alexander Friese <[email protected]>
@alexf2015
Scene calls sometimes get lost, thus the scene state is invalid and g…
b988999 
…ets stuck. Therefore scene activation events should always trigger the activation logic, even if the internal state is already "active"

Signed-off-by: Alexander Friese <[email protected]>
@alexf2015
fixed a "loop" in restart process which resulted in a stack overflow …
efa854a 
…exception and could even affect whole openhab instance.

Signed-off-by: Alexander Friese <[email protected]>
@alexf2015
this should fix openhab#8214 which is caused by a multi-threaded acce…
1f9bebd 
…ss to "pollingSchedulers"

Signed-off-by: Alexander Friese <[email protected]>
@TravisBuddy
Copy link

Travis tests were successful

Hey @alexf2015,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

@Hilbrand Hilbrand added bug An unexpected problem or unintended behavior of an add-on enhancement An enhancement or new feature for an existing add-on labels Aug 31, 2020
kaikreuzer
kaikreuzer approved these changes Aug 31, 2020
View reviewed changes
Copy link
Member

@kaikreuzer kaikreuzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@kaikreuzer kaikreuzer added this to the 2.5.9 milestone Aug 31, 2020
@kaikreuzer kaikreuzer merged commit 124d9d9 into openhab:2.5.x Aug 31, 2020
andrewfg pushed a commit to andrewfg/openhab-addons that referenced this pull request Aug 31, 2020
@alexf2015 @andrewfg
[Digitalstrom] Bugfixes/Improvements (openhab#8372)
e090314 
* added specific error handling for SSLHandshakeExecptions
logging
* Scene calls sometimes get lost, thus the scene state is invalid and gets stuck. Therefore scene activation events should always trigger the activation logic, even if the internal state is already "active"
* fixed a "loop" in restart process which resulted in a stack overflow exception and could even affect whole openhab instance.
* this should fix openhab#8214 which is caused by a multi-threaded access to "pollingSchedulers"

Signed-off-by: Alexander Friese <[email protected]>
andrewfg pushed a commit to andrewfg/openhab-addons that referenced this pull request Aug 31, 2020
@alexf2015 @andrewfg
[Digitalstrom] Bugfixes/Improvements (openhab#8372)
fb9eef3 
* added specific error handling for SSLHandshakeExecptions
logging
* Scene calls sometimes get lost, thus the scene state is invalid and gets stuck. Therefore scene activation events should always trigger the activation logic, even if the internal state is already "active"
* fixed a "loop" in restart process which resulted in a stack overflow exception and could even affect whole openhab instance.
* this should fix openhab#8214 which is caused by a multi-threaded access to "pollingSchedulers"

Signed-off-by: Alexander Friese <[email protected]>
andrewfg pushed a commit to andrewfg/openhab-addons that referenced this pull request Aug 31, 2020
@alexf2015 @andrewfg
[Digitalstrom] Bugfixes/Improvements (openhab#8372)
2e184bb 
* added specific error handling for SSLHandshakeExecptions
logging
* Scene calls sometimes get lost, thus the scene state is invalid and gets stuck. Therefore scene activation events should always trigger the activation logic, even if the internal state is already "active"
* fixed a "loop" in restart process which resulted in a stack overflow exception and could even affect whole openhab instance.
* this should fix openhab#8214 which is caused by a multi-threaded access to "pollingSchedulers"

Signed-off-by: Alexander Friese <[email protected]>
andrewfg pushed a commit to andrewfg/openhab-addons that referenced this pull request Aug 31, 2020
@alexf2015 @andrewfg
[Digitalstrom] Bugfixes/Improvements (openhab#8372)
5b120cd 
* added specific error handling for SSLHandshakeExecptions
logging
* Scene calls sometimes get lost, thus the scene state is invalid and gets stuck. Therefore scene activation events should always trigger the activation logic, even if the internal state is already "active"
* fixed a "loop" in restart process which resulted in a stack overflow exception and could even affect whole openhab instance.
* this should fix openhab#8214 which is caused by a multi-threaded access to "pollingSchedulers"

Signed-off-by: Alexander Friese <[email protected]>
DaanMeijer pushed a commit to DaanMeijer/openhab-addons that referenced this pull request Sep 1, 2020
@alexf2015 @DaanMeijer
[Digitalstrom] Bugfixes/Improvements (openhab#8372)
24a01e4 
* added specific error handling for SSLHandshakeExecptions
logging
* Scene calls sometimes get lost, thus the scene state is invalid and gets stuck. Therefore scene activation events should always trigger the activation logic, even if the internal state is already "active"
* fixed a "loop" in restart process which resulted in a stack overflow exception and could even affect whole openhab instance.
* this should fix openhab#8214 which is caused by a multi-threaded access to "pollingSchedulers"

Signed-off-by: Alexander Friese <[email protected]>
Signed-off-by: Daan Meijer <[email protected]>
@gaetancollaud
Copy link
Contributor

Thanks for this. I was investigating some issues and found out that you already solve them !

Awesome work !

CSchlipp pushed a commit to CSchlipp/openhab-addons that referenced this pull request Sep 12, 2020
@alexf2015 @CSchlipp
[Digitalstrom] Bugfixes/Improvements (openhab#8372)
e9b3c58 
* added specific error handling for SSLHandshakeExecptions
logging
* Scene calls sometimes get lost, thus the scene state is invalid and gets stuck. Therefore scene activation events should always trigger the activation logic, even if the internal state is already "active"
* fixed a "loop" in restart process which resulted in a stack overflow exception and could even affect whole openhab instance.
* this should fix openhab#8214 which is caused by a multi-threaded access to "pollingSchedulers"

Signed-off-by: Alexander Friese <[email protected]>
markus7017 pushed a commit to markus7017/openhab-addons that referenced this pull request Sep 19, 2020
@alexf2015 @markus7017
[Digitalstrom] Bugfixes/Improvements (openhab#8372)
1c00235 
* added specific error handling for SSLHandshakeExecptions
logging
* Scene calls sometimes get lost, thus the scene state is invalid and gets stuck. Therefore scene activation events should always trigger the activation logic, even if the internal state is already "active"
* fixed a "loop" in restart process which resulted in a stack overflow exception and could even affect whole openhab instance.
* this should fix openhab#8214 which is caused by a multi-threaded access to "pollingSchedulers"

Signed-off-by: Alexander Friese <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@kaikreuzer kaikreuzer kaikreuzer approved these changes

Assignees
No one assigned
Labels
bug An unexpected problem or unintended behavior of an add-on enhancement An enhancement or new feature for an existing add-on
Projects
None yet
Milestone
2.5.9
Development

Successfully merging this pull request may close these issues.
5 participants
@alexf2015 @TravisBuddy @gaetancollaud @kaikreuzer @Hilbrand