NIFI-13544 Add property to set the size of the threadpool of pubsub p…

[PACordonnier]

…ublish

Summary

NIFI-13544

The PR adds a setting to the PublishGCPPubSub processor limiting the number of threads to be used by the processor. By default (if empty) use the default behaviour of having (5 * Number of CPU) threads per processor.

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

[exceptionfactory]

Thanks for proposing this improvement @PACordonnier.

Given the behavior described, having a defined thread pool size makes sense. Rather than making it configurable, or supporting the existing behavior, I recommend setting the fixed number based on the maximum number of concurrent tasks configured for the Processor. The Concurrent Tasks control how many framework threads can invoke the Processor simultaneously, and that should align reasonably to the number of threads for the Publisher. Starting with that also avoids introducing a new property. If we do proceed to introduce a new property, the default could be set to the number of detected runtime processors, instead of the auto value as the existing behavior seems undesirable across the board.

[pvillard31]

@PACordonnier @exceptionfactory - as we're closing out items for 2.0 release, I took the liberty of making an update on this PR and file #9454 to address the comments and align the thread pool size with the number of concurrent tasks.