exceptionfactory commented on PR #8013: URL: https://github.com/apache/nifi/pull/8013#issuecomment-1883957266
> I have one more open question: cleaning up the obsolete items from the state when the user changes the flow and configures e.g. a new event hub or consumer group on the processor. In this case the old ownership and checkpoint data remains persisted in the state currently. Clearing the state is the user's responsibility now. On the other hand, it also means that the user has the option to go back to the original settings and continue with those checkpoints. In general, I would opt for cleaning up the state after configuration changes and storing only the current checkpoints (state size, no outdated items). Unfortunately, there is no trivial way to clear the state (`StateManager.clear()` cannot be used due to the concurrent access in the cluster) and it was implemented without clean-up in the original PR so I did not change it. However, now it looks feasible to me and it may be worth implementing the clean-up logic. What is your opinion? Thanks for the updates @turcsanyip, sorry for the delay in response. Given that other components require manual intervention to clear the state, that seems reasonable on its own. That might also be more intuitive than automatically clearing the state based on configuration changes, even though it requires an extra step. I plan to take a closer look at the other changes soon, but otherwise this looks close to completion, so perhaps that is worth considering as a follow-on task? -- 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]
