Merge lp:~afrantzis/mir/fix-1201436-more into lp:mir
Status: | Merged |
---|---|
Approved by: | Daniel van Vugt |
Approved revision: | no longer in the source branch. |
Merged at revision: | 1154 |
Proposed branch: | lp:~afrantzis/mir/fix-1201436-more |
Merge into: | lp:mir |
Diff against target: |
351 lines (+165/-49) 4 files modified
src/client/mir_client_library.cpp (+76/-24) src/client/mir_connection.cpp (+13/-24) src/client/rpc/mir_socket_rpc_channel.cpp (+1/-1) tests/acceptance-tests/test_server_disconnect.cpp (+75/-0) |
To merge this branch: | bzr merge lp:~afrantzis/mir/fix-1201436-more |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Daniel van Vugt | Abstain | ||
Robert Carr (community) | Approve | ||
Alan Griffiths | Approve | ||
PS Jenkins bot (community) | continuous-integration | Approve | |
Review via email: mp+191784@code.launchpad.net |
Commit message
client: Allow clients to call API functions after a connection break has been detected
When a client tries to call an API function after a connection break has
been detected in a previous API call, the client blocks in the new call.
This happens because in MirSocketRpcCha
pending RPC calls are not forced to complete, since the channel has already
been marked as 'disconnected' by the failure in the previous call.
Note that if the break is first detected while calling an API function,
then that call doesn't block, since this is the first time we call
MirSocketRpcCha
forced to complete.
This commit solves this problem by always forcing requests to complete
when a communication failure occurs, even if a disconnection has
already been handled. This is preferred over the alternative of
manually calling the completion callback in a try-catch block when
calling an RPC method because of:
1. Correctness: In case the communication problem first occurs in that
call, the callback will be called twice, once by notify_
and once manually.
2. Consistency: The callback is called from one place regardless of
whether the communication problem is first detected during that
call or not.
Description of the change
client: Allow clients to call API functions after a connection break has been detected
When a client tries to call an API function after a connection break has
been detected in a previous API call, the client blocks in the new call.
This happens because in MirSocketRpcCha
pending RPC calls are not forced to complete, since the channel has already
been marked as 'disconnected' by the failure in the previous call.
Note that if the break is first detected while calling an API function,
then that call doesn't block, since this is the first time we call
MirSocketRpcCha
forced to complete.
This commit solves this problem by always forcing requests to complete
when a communication failure occurs, even if a disconnection has
already been handled. This is preferred over the alternative of
manually calling the completion callback in a try-catch block when
calling an RPC method because of:
1. Correctness: In case the communication problem first occurs in that
call, the callback will be called twice, once by notify_
and once manually.
2. Consistency: The callback is called from one place regardless of
whether the communication problem is first detected during that
call or not.
I took this opportunity to do some other (somewhat related) cleanup in the client API implemenation.
PASSED: Continuous integration, rev:1150 jenkins. qa.ubuntu. com/job/ mir-team- mir-development -branch- ci/195/ jenkins. qa.ubuntu. com/job/ mir-android- saucy-i386- build/2417 jenkins. qa.ubuntu. com/job/ mir-clang- saucy-amd64- build/2302 jenkins. qa.ubuntu. com/job/ mir-team- mir-development -branch- saucy-amd64- ci/192 jenkins. qa.ubuntu. com/job/ mir-team- mir-development -branch- saucy-amd64- ci/192/ artifact/ work/output/ *zip*/output. zip
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
Click here to trigger a rebuild: 10.97.0. 26:8080/ job/mir- team-mir- development- branch- ci/195/ rebuild
http://