Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

PACordonnier
Copy link

…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

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

Copy link
Contributor

@exceptionfactory exceptionfactory left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants