Skip to content

GH-2423: Upgrade to Kafka 3.3.1, Streams Proc. API #2427

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

Merged
merged 2 commits into from
Oct 3, 2022

Conversation

garyrussell
Copy link
Contributor

Resolves #2423

Upgrade Apache Kafka version to 3.3.1.

Migrate transformers to the new processor API.

Resolves spring-projects#2423

Upgrade Apache Kafka version to 3.3.1.

Migrate transformers to the new processor API.
@artembilan artembilan merged commit 239e350 into spring-projects:main Oct 3, 2022
garyrussell added a commit to garyrussell/spring-kafka that referenced this pull request Oct 24, 2022
Resolves spring-projects#2457

Previously, classifying `RuntimeException` either for no retries or for
blocking retries would cause undesirable effects - its classification
would be found first because the classifier first traverses up the
class hierarchy to find a match before traversing down the cause links.

When classifying exception for retry, unwrap the 'LEFE' cause from a
`TimestampedException` and/or `ListenerExecutionFailedException` so
that the classification is made on that cause.

By default, the retry classifier has no classified exceptions when
used in "classify for retry" mode (instead of the default "classify
for no retry" mode). This means that, if `retryOn(RuntimeException.class)`
is used, then all `RuntimeException`s will be retried (including those
that are usually considered fatal).

With mixed blocking/non-blocking retries, change the behavior to include
the standard fatal exceptions in case the user configures all `RuntimeException`s
to use blocking retries.

Also tested with a Boot app to see that a conversion exception bypasses
all retries and goes straight to the DLT.
garyrussell added a commit to garyrussell/spring-kafka that referenced this pull request Oct 24, 2022
Resolves spring-projects#2457

Previously, classifying `RuntimeException` either for no retries or for
blocking retries would cause undesirable effects - its classification
would be found first because the classifier first traverses up the
class hierarchy to find a match before traversing down the cause links.

When classifying exception for retry, unwrap the 'LEFE' cause from a
`TimestampedException` and/or `ListenerExecutionFailedException` so
that the classification is made on that cause.

By default, the retry classifier has no classified exceptions when
used in "classify for retry" mode (instead of the default "classify
for no retry" mode). This means that, if `retryOn(RuntimeException.class)`
is used, then all `RuntimeException`s will be retried (including those
that are usually considered fatal).

With mixed blocking/non-blocking retries, change the behavior to include
the standard fatal exceptions in case the user configures all `RuntimeException`s
to use blocking retries.

Also tested with a Boot app to see that a conversion exception bypasses
all retries and goes straight to the DLT.
artembilan pushed a commit that referenced this pull request Oct 24, 2022
Resolves #2457

Previously, classifying `RuntimeException` either for no retries or for
blocking retries would cause undesirable effects - its classification
would be found first because the classifier first traverses up the
class hierarchy to find a match before traversing down the cause links.

When classifying exception for retry, unwrap the 'LEFE' cause from a
`TimestampedException` and/or `ListenerExecutionFailedException` so
that the classification is made on that cause.

By default, the retry classifier has no classified exceptions when
used in "classify for retry" mode (instead of the default "classify
for no retry" mode). This means that, if `retryOn(RuntimeException.class)`
is used, then all `RuntimeException`s will be retried (including those
that are usually considered fatal).

With mixed blocking/non-blocking retries, change the behavior to include
the standard fatal exceptions in case the user configures all `RuntimeException`s
to use blocking retries.

Also tested with a Boot app to see that a conversion exception bypasses
all retries and goes straight to the DLT.
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.

Refactor Transformers as Processors
2 participants