-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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.
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
[innogysmarthome] Fix possible resource leak #8080
Conversation
Travis tests were successfulHey @lolodomo, |
55a0485
to
efec76f
Compare
Travis tests were successfulHey @lolodomo, |
Related to openhab#8027 Signed-off-by: Laurent Garnier <[email protected]>
efec76f
to
1d13aac
Compare
Travis tests were successfulHey @lolodomo, |
Related to openhab#8027 Signed-off-by: Laurent Garnier <[email protected]>
Related to openhab#8027 Signed-off-by: Laurent Garnier <[email protected]> Signed-off-by: CSchlipp <[email protected]>
@lolodomo This fix seems to have negative side-effects. :-( The line "client.stop();" causes that the method org.openhab.binding.innogysmarthome.internal.InnogyWebSocket#onClose() is called with status "1006" (Status.NO_CLOSE or Status.ABNORMAL) and that causes that the a reconnect attempt is executed. That leads to an infinite loop (at least since my pull-request #8186 which fixed that no reconnect attempts were executed ... ;-)). Why is the status 1006 (NO_CLOSE / ABNORMAL) when this issue should fix false closed websockets? How can it get closed with status 1000 (NORMAL)? |
You can revert my change if it leads to a problem. |
Related to openhab#8027 Signed-off-by: Laurent Garnier <[email protected]> Signed-off-by: MPH80 <[email protected]>
* When an error occurs, it is waited at least for 30 seconds to avoid too many requests (on re-occurring errors). * Workaround for side-effect of "Fix possible resource leak #8080" - Improved by not rescheduling when the close/stop was actively triggered by the binding (in this case there is already a reschedule triggered) * NPE fixed * Code-Optimization Closes #8182 Signed-off-by: Sven Strohschein <[email protected]>
* When an error occurs, it is waited at least for 30 seconds to avoid too many requests (on re-occurring errors). * Workaround for side-effect of "Fix possible resource leak openhab#8080" - Improved by not rescheduling when the close/stop was actively triggered by the binding (in this case there is already a reschedule triggered) * NPE fixed * Code-Optimization Closes openhab#8182 Signed-off-by: Sven Strohschein <[email protected]> Signed-off-by: Clayton Tabone <[email protected]>
Related to openhab#8027 Signed-off-by: Laurent Garnier <[email protected]>
* When an error occurs, it is waited at least for 30 seconds to avoid too many requests (on re-occurring errors). * Workaround for side-effect of "Fix possible resource leak openhab#8080" - Improved by not rescheduling when the close/stop was actively triggered by the binding (in this case there is already a reschedule triggered) * NPE fixed * Code-Optimization Closes openhab#8182 Signed-off-by: Sven Strohschein <[email protected]>
Related to openhab#8027 Signed-off-by: Laurent Garnier <[email protected]>
* When an error occurs, it is waited at least for 30 seconds to avoid too many requests (on re-occurring errors). * Workaround for side-effect of "Fix possible resource leak openhab#8080" - Improved by not rescheduling when the close/stop was actively triggered by the binding (in this case there is already a reschedule triggered) * NPE fixed * Code-Optimization Closes openhab#8182 Signed-off-by: Sven Strohschein <[email protected]>
Related to openhab#8027 Signed-off-by: Laurent Garnier <[email protected]>
* When an error occurs, it is waited at least for 30 seconds to avoid too many requests (on re-occurring errors). * Workaround for side-effect of "Fix possible resource leak openhab#8080" - Improved by not rescheduling when the close/stop was actively triggered by the binding (in this case there is already a reschedule triggered) * NPE fixed * Code-Optimization Closes openhab#8182 Signed-off-by: Sven Strohschein <[email protected]>
Related to openhab#8027 Signed-off-by: Laurent Garnier <[email protected]>
* When an error occurs, it is waited at least for 30 seconds to avoid too many requests (on re-occurring errors). * Workaround for side-effect of "Fix possible resource leak openhab#8080" - Improved by not rescheduling when the close/stop was actively triggered by the binding (in this case there is already a reschedule triggered) * NPE fixed * Code-Optimization Closes openhab#8182 Signed-off-by: Sven Strohschein <[email protected]>
Related to openhab#8027 Signed-off-by: Laurent Garnier <[email protected]> Signed-off-by: Daan Meijer <[email protected]>
* When an error occurs, it is waited at least for 30 seconds to avoid too many requests (on re-occurring errors). * Workaround for side-effect of "Fix possible resource leak openhab#8080" - Improved by not rescheduling when the close/stop was actively triggered by the binding (in this case there is already a reschedule triggered) * NPE fixed * Code-Optimization Closes openhab#8182 Signed-off-by: Sven Strohschein <[email protected]> Signed-off-by: Daan Meijer <[email protected]>
* When an error occurs, it is waited at least for 30 seconds to avoid too many requests (on re-occurring errors). * Workaround for side-effect of "Fix possible resource leak openhab#8080" - Improved by not rescheduling when the close/stop was actively triggered by the binding (in this case there is already a reschedule triggered) * NPE fixed * Code-Optimization Closes openhab#8182 Signed-off-by: Sven Strohschein <[email protected]>
Related to openhab#8027 Signed-off-by: Laurent Garnier <[email protected]>
* When an error occurs, it is waited at least for 30 seconds to avoid too many requests (on re-occurring errors). * Workaround for side-effect of "Fix possible resource leak openhab#8080" - Improved by not rescheduling when the close/stop was actively triggered by the binding (in this case there is already a reschedule triggered) * NPE fixed * Code-Optimization Closes openhab#8182 Signed-off-by: Sven Strohschein <[email protected]>
Related to #8027
Signed-off-by: Laurent Garnier [email protected]