arpadboda commented on a change in pull request #683: MINIFICPP-1087 - Proper
handling of errors during onSchedule calls
URL: https://github.com/apache/nifi-minifi-cpp/pull/683#discussion_r351783220
##########
File path: libminifi/src/core/ProcessGroup.cpp
##########
@@ -136,13 +147,14 @@ void ProcessGroup::removeProcessGroup(ProcessGroup
*child) {
}
}
-void ProcessGroup::startProcessing(const
std::shared_ptr<TimerDrivenSchedulingAgent> timeScheduler, const
std::shared_ptr<EventDrivenSchedulingAgent> &eventScheduler,
- const
std::shared_ptr<CronDrivenSchedulingAgent> &cronScheduler) {
+void ProcessGroup::startProcessingProcessors(const
std::shared_ptr<TimerDrivenSchedulingAgent> timeScheduler,
+ const std::shared_ptr<EventDrivenSchedulingAgent> &eventScheduler, const
std::shared_ptr<CronDrivenSchedulingAgent> &cronScheduler) {
std::lock_guard<std::recursive_mutex> lock(mutex_);
- try {
- // Start all the processor node, input and output ports
- for (const auto &processor : processors_) {
+ std::set<std::shared_ptr<Processor> > failed_processors;
+
+ for (const auto &processor : failed_processors_) {
+ try {
Review comment:
In my opinion, yes, because of:
-We can assume that in real production systems onSchedule errors are mostly
transient (network, etc), so a retry is going to fix them.
-What could we do to avoid such scenarios? We could do a BFS initiated from
the failed processor and unschedule all the sources, but in my opinion that's
even worse: it's quite complex and we just achieve immediately loosing data
instead of buffering it to our connections.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
