-
-
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
[homematic] Solves stability issues with HmIP devices #7902
Conversation
The CCU gets unresponsive if several HmIP devices are installed and always "non-blocking" requests are used. By reducing the use to what is absolutely necessary, the problem can be avoide. Fixes #7762 Signed-off-by: Martin Herbst <[email protected]>
Travis tests were successfulHey @MHerbst, |
return new RpcResponseParser(request).parse(data); | ||
} catch (UnknownRpcFailureException | UnknownParameterSetException ex) { | ||
throw ex; | ||
} catch (Exception ex) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it absolutely necessary to catch Exception
here?
*/ | ||
private synchronized Object[] sendMessage(int port, RpcRequest<String> request, int rpcRetryCounter) | ||
throws IOException { | ||
private byte[] send(int port, RpcRequest<String> request) throws Exception { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please do not throw Exception
, either define your own like HomematicException extends Exception
or use something like IllegalStateException
(or what fits best) and catch only that one. The problem with catchin Exception
is that it hides programming errors like NPE.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you regarding the catching and throwing of "Exception", but I tried to stay close to the original implementation and Jetty throws a lot of different exceptions. Will try to get rid of the Exception.
Signed-off-by: Martin Herbst <[email protected]>
Travis tests were successfulHey @MHerbst, |
} else { | ||
logger.warn("Non-blocking XmlRpcRequest failed, status code: {} / request: {}", httpStatus, | ||
request); | ||
resp.abort(new Exception()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resp.abort(new Exception()); | |
resp.abort(new IOException()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
Signed-off-by: Martin Herbst <[email protected]>
Travis tests were successfulHey @MHerbst, |
* Solves stability issues with HmIP devices The CCU gets unresponsive if several HmIP devices are installed and always "non-blocking" requests are used. By reducing the use to what is absolutely necessary, the problem can be avoide. Fixes openhab#7762 Signed-off-by: Martin Herbst <[email protected]>
* Solves stability issues with HmIP devices The CCU gets unresponsive if several HmIP devices are installed and always "non-blocking" requests are used. By reducing the use to what is absolutely necessary, the problem can be avoide. Fixes openhab#7762 Signed-off-by: Martin Herbst <[email protected]> Signed-off-by: CSchlipp <[email protected]>
* Solves stability issues with HmIP devices The CCU gets unresponsive if several HmIP devices are installed and always "non-blocking" requests are used. By reducing the use to what is absolutely necessary, the problem can be avoide. Fixes openhab#7762 Signed-off-by: Martin Herbst <[email protected]>
* Solves stability issues with HmIP devices The CCU gets unresponsive if several HmIP devices are installed and always "non-blocking" requests are used. By reducing the use to what is absolutely necessary, the problem can be avoide. Fixes openhab#7762 Signed-off-by: Martin Herbst <[email protected]>
* Solves stability issues with HmIP devices The CCU gets unresponsive if several HmIP devices are installed and always "non-blocking" requests are used. By reducing the use to what is absolutely necessary, the problem can be avoide. Fixes openhab#7762 Signed-off-by: Martin Herbst <[email protected]>
* Solves stability issues with HmIP devices The CCU gets unresponsive if several HmIP devices are installed and always "non-blocking" requests are used. By reducing the use to what is absolutely necessary, the problem can be avoide. Fixes openhab#7762 Signed-off-by: Martin Herbst <[email protected]>
* Solves stability issues with HmIP devices The CCU gets unresponsive if several HmIP devices are installed and always "non-blocking" requests are used. By reducing the use to what is absolutely necessary, the problem can be avoide. Fixes openhab#7762 Signed-off-by: Martin Herbst <[email protected]> Signed-off-by: Daan Meijer <[email protected]>
* Solves stability issues with HmIP devices The CCU gets unresponsive if several HmIP devices are installed and always "non-blocking" requests are used. By reducing the use to what is absolutely necessary, the problem can be avoide. Fixes openhab#7762 Signed-off-by: Martin Herbst <[email protected]>
The CCU gets unresponsive if several HmIP devices are installed and
always "non-blocking" requests are used. By reducing the use to what is
absolutely necessary, the problem can be avoided.
Fixes #7762
Signed-off-by: Martin Herbst [email protected]