adamdebreceni commented on pull request #974: URL: https://github.com/apache/nifi-minifi-cpp/pull/974#issuecomment-759273848
> > Wonder if tasks need to have the property to indicate paused state. > > So currently I think we have a dedicated threadpool for c2 (heartbeating). Because of this the flowcontroller's threadpool can be completely paused. > > In this case the scheduling agent and the tasks don't need to be impacted, only the threadpool workers top picking up tasks while the flowcontroller is paused. > > What do you think? > > That's actually what I wanted to go with first, but a problem occurred when I implemented it. When the ThreadPool dequeues the worker queue and sees that the dequeued task is in stopped state it does not re-enqueue the task, but simply throws it away. The task remains in the task states map, but changing its state has no effect afterwards. This is why I wanted to distinguish a stopped task from a paused task by moving the paused tasks to separate map when they are processed and later re-enqueueing them when they are resumed thus keeping the original behavior of the stopped tasks. I feel like there are two contending "pause/resume" operation semantics, one regarding the FlowController (@arpadboda ), and one regarding the processors (@lordgamez) 1. which one is the current PR about? (it seem to me, that the first one) 2. if the first one, do we plan on extending it to support the second one? 3. if the first one, and we don't plan on supporting processor-level pause/resume why doesn't a ThreadPool simply stop dequeuing tasks on pause ---------------------------------------------------------------- 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: us...@infra.apache.org
