-
Notifications
You must be signed in to change notification settings - Fork 1
Bugfix/#69 fix action pipeline deadlocks and other issues that cause random action cancelations. #89
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
Bugfix/#69 fix action pipeline deadlocks and other issues that cause random action cancelations. #89
Conversation
…nTaskLock in ActionImpl.
…tting down to avoid lots of exceptions.
… changes to not interfear with future scene activations. Improve required state validation by filtering by validate the initial action to avoid scene cancelation based on an outdated action. Minor typo fixes.
…her actions that are later observed by the same remote instance, by canceling the cleanup task once the remote is reinitialized.
…of test prints vs. setup / cleanup prints
…pipeline_deadlocks_and_other_pipeline_issues
pLeminoq
left a comment
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.
Overall, a really nice PR. I just have suggestions for a few minor changes and I think the actionTask issue has to be discussed.
|
|
||
| // any code that accesses the data lock while holding the action task lock should previously lock the data lock. | ||
| // otherwise deadlocks can occur. |
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.
This comment is not entirely clear to me, especially with regard to the proposed change below. There are two possibilities:
- We always need to acquire the data lock if we need the the action task lock and the data lock has to be acquired first.
- We don't need to acquire the data lock in every case we need the action task look. But if we do, the data lock has to be acquired first.
I think you mean option 2. But in light of the proposed change below, this is not easily visible since the requirement to acquire the data lock is hidden in the isTerminating() call.
In general, I think the usage of such a comment is sub-optimal as you will not see this comment during coding. Would it be possible to implement a structure where when you acquire the action task lock, you have to consciously decide if you also need to acquire the data lock?
...control/src/main/java/org/openbase/bco/dal/control/layer/unit/scene/SceneControllerImpl.java
Outdated
Show resolved
Hide resolved
...control/src/main/java/org/openbase/bco/dal/control/layer/unit/scene/SceneControllerImpl.java
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| // register an observer which will deactivate the scene if one required action is now longer running | ||
| // observer will cleanup itself after the action is no longer valid so no need to care fore it. |
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 guess the second line of this comment is now outdated and should be removed.
|
|
||
| private void verifyAllStates() { | ||
| try { | ||
| // logger.trace("verify "+unitAndRequiredServiceStateMap.entrySet().size()+ " states of "+ getLabel("?")); |
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.
Maybe remove commented debug log
| @Override | ||
| public void update(ServiceStateProvider<Message> serviceStateProvider, Message serviceState) throws Exception { | ||
| try { | ||
| // logger.error("Incomming service state update from "+ serviceStateProvider.getServiceProvider().getId() + " triggered from "+ serviceState.toString()); |
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.
Maybe remove commented log
module/dal/remote/src/main/java/org/openbase/bco/dal/remote/action/Actions.java
Outdated
Show resolved
Hide resolved
module/dal/remote/src/main/java/org/openbase/bco/dal/remote/action/RemoteAction.java
Outdated
Show resolved
Hide resolved
| if (description == null && actionReference != null) { | ||
| description = ActionDescriptionProcessor.toString(actionReference); | ||
| } | ||
|
|
||
| // resolve via parameter | ||
| if (actionParameter != null) { | ||
| return ActionDescriptionProcessor.toString(actionParameter); | ||
| } | ||
| // resolve via parameter | ||
| if (description == null && actionParameter != null) { | ||
| description = ActionDescriptionProcessor.toString(actionParameter); |
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.
Since the description is set to an empty string above you description.isEmpty() should be used instead of the null checks.
|
|
||
| LOGGER.warn("turn off..."); | ||
| waitForExecution(sceneRemoteOff.setActivationState(State.ACTIVE, SCENE_ACTION_PARAM)); | ||
| LOGGER.warn("turn off... continue"); |
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.
Are these debugging logs still required?
…layer/unit/scene/SceneControllerImpl.java Co-authored-by: pLeminoq <thuxohl@techfak.uni-bielefeld.de>
Co-authored-by: pLeminoq <thuxohl@techfak.uni-bielefeld.de>
…line_issues' of https://github.com/openbase/bco into bugfix/#69_fix_action_pipeline_deadlocks_and_other_pipeline_issues
|
Thanks for the detailed review. All conversations are addressed, so PR is ready to review again. |
📜 Description
Changes proposed in this pull request: