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.

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

Fix/ccb 3141 change command request inheritance structure #3591

Conversation

VladSemenyuk
Copy link
Contributor

@VladSemenyuk VladSemenyuk commented Dec 7, 2020

Fixes #3141, #2935
This PR is ready for review.

Risk

This PR makes no API changes.

Testing Plan

Unit tests, ATF

Summary

  • Changed commands requests inheritance structure.
  • Fixed data races in request controller.
Enhancements
  • CommonRequestImpl class was reworked in order to keep only common
    requests logic. Created new class - RequestFromMobile for logic specific for mobile
    requests only.
    image
    image

  • Reworked logic of handling requests with multiple interfaces.
    Used common methods for checks of pending requests.

  • Functions OnUpdateTimeOut and HahdleOnEvent added to CommandRequestImpl for correct synchorization and processing of current request state, that helps to avoid data races.
    Current states processing:
    image

Bug Fixes
  1. Fix data races in request controller

There was a problem that request controller might
destroy the command which is currently executed by
another thread in case of application disconnect.
When app gets disconnected, SDL destroys all pending
and waiting for response requests belongs to
unregistered application. Data race is happening
when request controller destroys the command which
is currently handles response. To resolve this data
race the following changes were done:

  • terminateWaitingForResponseAppRequests function
    was updated to iterate over all pending requests and
    consider possibility to terminate it via CleanUp()
    call. Requests will be terminated only in case of
    successful cleanup
  • During cleanup, mobile requests unsubscribes from
    all events to avoid getting kProcessEvent state
  • Cleanup is considered as successful in case if
    command is in kAwaiting state
  • In case the command in:
    kAwaitingResponse - command will be dropped by
    request controller as usual as there no data races
    kTimedOut - command is executing OnTimeout() call.
    Request controller will keep this command in
    waiting_for_response_ list as it will be dropped
    later by another thread after OnTimeout() execution
    kProcessEvent - command is executing on_event() call.
    Request controller will keep this command in
    waiting_for_response_ list as it will be dropped
    later by another thread after on_event() execution
  1. Prevent command destruction after on_event

Was added workaround to prevent command destruction
after on_event() call because some additional acitons
should be done after that. Workaround is to retain
requests shared pointer instance before on_event()
and release it after on_event() and state check.
This allows to remove another workaround logic and
provides better control on a command lifetime from
the outside.

Tasks Remaining:

  • [Task 1]
  • [Task 2]

CLA

@VladSemenyuk
Copy link
Contributor Author

VladSemenyuk commented Dec 7, 2020

@JackLivio this PR is ready for review

@jacobkeeler
Copy link
Contributor

Unfortunately since this PR includes major API changes (due to changes in the inheritance structure of several classes), we will likely need to wait for a major release to include these changes.

@jacobkeeler
Copy link
Contributor

As a note, we could include this by changing the coming April release to a major release for SDL Core, and this shouldn't affect any other releases so long as we don't include any major API changes to the RPC Spec.

@jordynmackool
Copy link

jordynmackool commented Mar 5, 2021

The Steering Committee voted on 2021-01-19 to not include PR #3591 resolving the prioritized Core issue #3141 in the April 14, 2021 releases.

@jordynmackool
Copy link

@VladSemenyuk this PR has conflicts that need to be resolved. Can you please resolve the conflict and then tag me when this PR is ready for Livio's review. Thanks!

@AKalinich-Luxoft
Copy link
Contributor

@VladSemenyuk this PR has conflicts that need to be resolved. Can you please resolve the conflict and then tag me when this PR is ready for Livio's review. Thanks!

@jordynmackool we have plans to resolve conflicts in this PR after merge of #3726 which is currently on Livio review because this PR has a lot of intersections with the current fix which will cause new conflicts. Please let me know if you have plans to merge this fix before the mentioned feature delivery.

@jordynmackool
Copy link

@AKalinich-Luxoft thanks for the update. Livio is aligned with your plan to wait for the merge of #3726 to then resolve the noted conflicts on this PR. Please tag me once this is ready for our review. Thanks!

@Jack-Byrne
Copy link
Collaborator

@AKalinich-Luxoft #3726 has been approved so the changes for this pr can be rebased now.

@AKalinich-Luxoft
Copy link
Contributor

AKalinich-Luxoft commented Jul 27, 2021

@AKalinich-Luxoft #3726 has been approved so the changes for this pr can be rebased now.

@JackLivio is it possible to merge #3726 to develop? The current fix is targeted to develop so it's better to rebase against this branch containing 3726

@Jack-Byrne
Copy link
Collaborator

@AKalinich-Luxoft I believe #3726 review is still in progress.

@theresalech
Copy link
Contributor

Hi @VladSemenyuk , #3726 has now been merged into develop. Can you please rebase this PR, resolve merge conflicts, and let us know when the PR is ready for Livio's review? Thank you!

@AKalinich-Luxoft
Copy link
Contributor

Hi @VladSemenyuk , #3726 has now been merged into develop. Can you please rebase this PR, resolve merge conflicts, and let us know when the PR is ready for Livio's review? Thank you!

@theresalech Luxoft is in progress with resolving all the conflicts and do our best to get this fixed on time

@jordynmackool
Copy link

Hi @AKalinich-Luxoft, Livio is going to begin Release candidate prep, starting on 2021-08-30. We will need to make progress on this PR asap for it to be included in the upcoming release. Can you please provide timing on when Luxoft will have this PR ready for Livio review? Thanks!

@Jack-Byrne
Copy link
Collaborator

@VladSemenyuk Hi, is this ready for review?

@AKalinich-Luxoft
Copy link
Contributor

@VladSemenyuk Hi, is this ready for review?

@JackLivio the major part of this fix is ready for Livio review and all merge conflicts have been resolved. Notice that some minor fixup commits are expected here to fix a regression found after merging the latest changes from the develop branch.

@Jack-Byrne
Copy link
Collaborator

@AKalinich-Luxoft Just wanted to note I am seeing failures in the test set for OnResetTimeout

test_scripts/API/Restructuring_OnResetTimeout/003_BC_OnResetTimeout_GENERIC_ERROR_in_case_HMI_did_not_respond.lua
test_scripts/API/Restructuring_OnResetTimeout/004_BC_OnResetTimeout_HMI_did_not_respond_notification_without_resetPeriod.lua
test_scripts/API/Restructuring_OnResetTimeout/006_BC_OnResetTimeout_with_wrong_methodName_and_HMI_did_not_respond.lua
test_scripts/API/Restructuring_OnResetTimeout/007_BC_OnResetTimeout_with_wrong_requestID_and_HMI_did_not_respond.lua
test_scripts/API/Restructuring_OnResetTimeout/015_BC_OnResetTimeout_ResetPeriod_is_zero.lua
test_scripts/API/Restructuring_OnResetTimeout/029_BC_OnResetTimeout_No_Reset_GENERIC_ERROR_non_zero_DefaultTimeoutCompensation.lua
test_scripts/API/Restructuring_OnResetTimeout/030_BC_OnResetTimeout_Reset_GENERIC_ERROR_non_zero_DefaultTimeoutCompensation.lua

That gives to event dispatcher some time to figure
out that event should not be rasied for a finalized request
and this request will be released soon. Also, this allows
to avoid calling some virtual functions on pointer to
invalidated object.
Now reference counter is increased indirectly
by event dispatcher before calling `HandleOnEvent()`
of specific observer.
This will guarantee that during `HandleOnEvent` the
command object is still be alive.
@AKalinich-Luxoft
Copy link
Contributor

@AKalinich-Luxoft Just wanted to note I am seeing failures in the test set for OnResetTimeout

test_scripts/API/Restructuring_OnResetTimeout/003_BC_OnResetTimeout_GENERIC_ERROR_in_case_HMI_did_not_respond.lua
test_scripts/API/Restructuring_OnResetTimeout/004_BC_OnResetTimeout_HMI_did_not_respond_notification_without_resetPeriod.lua
test_scripts/API/Restructuring_OnResetTimeout/006_BC_OnResetTimeout_with_wrong_methodName_and_HMI_did_not_respond.lua
test_scripts/API/Restructuring_OnResetTimeout/007_BC_OnResetTimeout_with_wrong_requestID_and_HMI_did_not_respond.lua
test_scripts/API/Restructuring_OnResetTimeout/015_BC_OnResetTimeout_ResetPeriod_is_zero.lua
test_scripts/API/Restructuring_OnResetTimeout/029_BC_OnResetTimeout_No_Reset_GENERIC_ERROR_non_zero_DefaultTimeoutCompensation.lua
test_scripts/API/Restructuring_OnResetTimeout/030_BC_OnResetTimeout_Reset_GENERIC_ERROR_non_zero_DefaultTimeoutCompensation.lua

@JackLivio thank you for mentioning this. All these scripts have been fixed in the latest commits and are now PASSED.

@AKalinich-Luxoft
Copy link
Contributor

@jordynmackool @JackLivio please notice that few more commits were pushed to this PR and now all regression tests are passed on our side which means that the current version of the fix has been finalized and no more changes are planned. You can proceed with the review of the entire fix now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants