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

Execute KafkaClient reactive and CompletableFuture methods with TaskExecutors.BLOCKING by default #956

Open
jeremyg484 opened this issue Jan 30, 2024 · 1 comment
Assignees
Labels
type: breaking Introduces a breaking change type: enhancement New feature or request

Comments

@jeremyg484
Copy link
Contributor

jeremyg484 commented Jan 30, 2024

Feature description

An executor configuration option was added in #955 for @KafkaClient beans that enables specifying an ExecutorService to use to make methods that return reactive and CompletableFuture return types fully non-blocking. To avoid breaking existing applications that may already be compensating for the existing behavior with use of facilities such as @ExecuteOn in their calling code, the executor configuration is left empty by default.

We should consider setting this configuration to TaskExecutors.BLOCKING by default in a future major release so that users may take advantage of the reactive style without having to worry about the underlying blocking that happens in calls to the KafkaProducer API. TaskExecutors.BLOCKING is a good fit for this use case since it defaults to virtual threads on Java 21+.

@jeremyg484 jeremyg484 added type: enhancement New feature or request type: breaking Introduces a breaking change labels Jan 30, 2024
@jeremyg484
Copy link
Contributor Author

Depending on the timing of the 5.0.0 release vs the release of Kafka 3.8.0, this may not be necessary. Work is in progress in Kafka to refactor the threading model used by KafkaConsumer.

See https://cwiki.apache.org/confluence/display/KAFKA/Consumer+threading+refactor for implementation details and status. If implemented as proposed, the client should be fully non-blocking when using the async APIs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: breaking Introduces a breaking change type: enhancement New feature or request
Projects
Status: Todo
Development

No branches or pull requests

1 participant