-
Notifications
You must be signed in to change notification settings - Fork 40.8k
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
Add support for configuring Pulsar listener container concurrency #42062
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the contribution @vpavic . I believe this is another property that makes sense to make available via config props.
I have a couple of comments/suggestions to follow up on.
Thanks
@@ -801,6 +802,11 @@ public static class Listener { | |||
*/ | |||
private SchemaType schemaType; | |||
|
|||
/** | |||
* Number of threads used by listener container. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be helpful to elaborate on this one just a bit, maybe something like:
Number of listener threads used by the container to process messages concurrently
Wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to aligned property description with these:
Lines 976 to 979 in c06027b
/** * Number of threads to run in the listener containers. */ private Integer concurrency; Lines 171 to 180 in c06027b
/** * Minimum number of concurrent consumers. When max-concurrency is not specified * the minimum will also be used as the maximum. */ private Integer minConcurrency; /** * Maximum number of concurrent consumers. */ private Integer maxConcurrency; Lines 852 to 860 in c06027b
/** * Minimum number of listener invoker threads. */ private Integer concurrency; /** * Maximum number of listener invoker threads. */ private Integer maxConcurrency;
As a user I'd probably prefer consistency in describing the same concept in different parts of auto-configuration, but whatever Spring Boot team prefers here is fine with me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tried to aligned property description with these
Yep, I saw those descriptions as well. I think there is room for improvement in the spring-kafka properties. This is really a nit and consistency is a good thing. As you said, let's see what Boot peepz think.
@@ -195,6 +197,13 @@ private void customizePulsarContainerListenerProperties(PulsarContainerPropertie | |||
map.from(properties::isObservationEnabled).to(containerProperties::setObservationEnabled); | |||
} | |||
|
|||
<T> void customizeConcurrentPulsarListenerContainerFactory( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just noticed that the listener containers on the framework side are inconsistent w/ the concurrency
attribute between reactive and imperative. I created this issue to simplify the latter.
If you wanted to handle that issue first it would then simplify this PR so that we would not need this new customizeConcurrentPulsarListenerContainerFactory
method and could simply map the property in customizePulsarContainerListenerProperties
instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I can pick up that issue on Spring Pulsar side. So basically this PR is then blocked until spring-projects/spring-pulsar#820 is resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I can pick up that issue on Spring Pulsar side. So basically this PR is then blocker until spring-projects/spring-pulsar#820 is resolved.
Thanks @vpavic . Yeh, I think we should do the spring-pulsar one first.
...oconfigure/src/main/java/org/springframework/boot/autoconfigure/pulsar/PulsarProperties.java
Show resolved
Hide resolved
This commit adds configuration property that allows users to configure Pulsar message listener container concurrency.
01e745e
to
7601951
Compare
Add a configuration property that allows users to configure Pulsar message listener container concurrency. See gh-42062
Thanks @vpavic! |
This is a follow-up to spring-projectsgh-42062 that utilizes newly introduced `concurrency` property in `PulsarContainerProperties` to simplify auto-configuration support for Pulsar listener container concurrency. See: spring-projects/spring-pulsar#820
@philwebb this was merged perhaps too soon as I didn't have chance to update this PR to benefit from the changes introduced in spring-projects/spring-pulsar#820. I've opened #42120 to address that separately. |
This is a follow-up to spring-projectsgh-42062 that utilizes newly introduced `concurrency` property in `PulsarContainerProperties` to simplify auto-configuration support for Pulsar listener container concurrency. See: spring-projects/spring-pulsar#820
This is a follow-up to spring-projectsgh-42062 that utilizes newly introduced `concurrency` property in `PulsarContainerProperties` to simplify auto-configuration support for Pulsar listener container concurrency. See: spring-projects/spring-pulsar#820
This is a follow-up to gh-42062 that utilizes newly introduced `concurrency` property in `PulsarContainerProperties` to simplify auto-configuration support for Pulsar listener container concurrency. See: spring-projects/spring-pulsar#820 See gh-42120
This commit adds configuration property that allows users to configure Pulsar message listener container concurrency.
In similar fashion to #42052, this is much needed to achieve optimal setup of message consumption, especially when dealing with partitioned topics.
/cc @onobc