lordgamez commented on code in PR #1840:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1840#discussion_r1679247201
##########
libminifi/src/core/ProcessGroup.cpp:
##########
@@ -200,7 +212,13 @@ void
ProcessGroup::startProcessing(TimerDrivenSchedulingAgent& timeScheduler, Ev
void ProcessGroup::stopProcessing(TimerDrivenSchedulingAgent& timeScheduler,
EventDrivenSchedulingAgent& eventScheduler,
CronDrivenSchedulingAgent& cronScheduler,
const std::function<bool(const Processor*)>& filter) {
- std::lock_guard<std::recursive_mutex> lock(mutex_);
Review Comment:
This and similar changes in the `startProcessingProcessors` and
`startProcessing` functions are to avoid deadlock. It appeared in
`ControllerServiceIntegrationTests` when `stop()` is called while the
`getControllerService` is called in the processor's `onTrigger`. The `stop()`
function waits for the processor's `onTrigger` to finish, but it cannot finish
the ProcessGroup's `findProcessor` method because it is waiting for the same
mutex which is held here.
We may need to find a better solution as this may cause some concurrency
issues I'm not currently aware of. I'm open for suggestions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
