NIFI-14399 Removed finalize method from StandardProcessSession.

[dan-s1]

Summary

NIFI-14399

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using mvn clean install -P contrib-check
  • JDK 21

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[dan-s1]

@markap14 When speaking with @exceptionfactory regarding this change, he felt the use of finalize() looks like a failsafe attempt to rollback dating back to project inception which now he feels should be removed but he wanted me to check with you since changes to StandardProcessSession are far more important and potentially dangerous.
Thank you for your help!

[joewitt]

I suppose if we have process sessions which are yet to be rolled back yet we've been willing to just let the reference dangle...we have deeper problems. Given the finalize call is going away there likely isn't much we can or should do here anyway. It was a nice peace of mind thing...

[sfc-gh-mpayne]

I think this is probably okay. This exists as a safeguard against buggy Processors. In particular, if you create a Processor that extends AbstractSessionFactoryProcessor, you have full control over the ProcessSession. This ensures that if that processor calls ProcessSession.read, ProcessSession.write etc. that we eventually can clean up those resources. And if it pulls FlowFiles off of a queue and never commits or rolls back the session they can eventually be re-queued without a restart of NiFi, instead of letting the FlowFiles kind of exist in the ether.

So it helped to kind of ensure that we do all we can to protect ourselves against buggy Processors. But at the end of the day, there's really only so much we can do. Processors can still open sockets, file handles, etc. and fail to close them and leak resources that way. And they could still potentially hold on to references to the Process Sessions, preventing the finalizer from being called also.

While I think it is nice to have it there, given the deprecation of finalizers, it's probably reasonable to just remove the method.

[dan-s1]

@sfc-gh-mpayne Thanks for getting back. Although finalize is going away the suggested replacement is the use of Cleaners. Is that something which should be looked into?

[joewitt]

interesting https://inside.java/2022/05/25/clean-cleaner/

[dan-s1]

@joewitt If we want to use Cleaners could a new ticket be created for that?

[exceptionfactory]

Based on Mark's response, I'm inclined to proceed with removing the finalize() method as proposed.

Implementing something based on a Cleaner sounds interesting, but also potentially complicated for a questionable amount of usefulness.

Either way, I think a different approach would be better to implement in a separate issue.

Marking as approved and planning to merge later today unless there are any objections before then.

[joewitt]

While we're waiting for you to merge this...does this mean this moment is.... the final countdown?

man i hope that joke lands as funny as it is in my own head

[dan-s1]

@joewitt Did you mean the finalize(d) countdown? :)

[joewitt]

always good to know who my fellow dad jokes/humor friends are. I see you!

[exceptionfactory]

As the discussion appears to be finalized, I will proceed with merging. Thanks all!