-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
KafkaItemWriter should wait for results of kafkaTemplate.sendDefault call #3773
Labels
for: backport-to-4.2.x
Issues that will be back-ported to the 4.2.x line
in: infrastructure
related-to: item-readers-writers
type: bug
Milestone
Comments
jbotuck
added
status: waiting-for-triage
Issues that we did not analyse yet
type: feature
labels
Sep 11, 2020
jbotuck
added a commit
to jbotuck/spring-batch
that referenced
this issue
Jan 5, 2021
…til items are confirmed to have been written
fmbenhassine
added
has: backports
Legacy label from JIRA. Superseded by "for: backport-to-x.x.x"
in: infrastructure
type: bug
and removed
status: waiting-for-triage
Issues that we did not analyse yet
type: feature
labels
Jan 15, 2021
fmbenhassine
added
for: backport-to-4.2.x
Issues that will be back-ported to the 4.2.x line
related-to: item-readers-writers
and removed
has: backports
Legacy label from JIRA. Superseded by "for: backport-to-x.x.x"
labels
Jan 21, 2021
jbotuck
added a commit
to jbotuck/spring-batch
that referenced
this issue
Feb 2, 2021
…til items are confirmed to have been written
fmbenhassine
added a commit
that referenced
this issue
Mar 9, 2021
Fixed in #3827 . |
fmbenhassine
added a commit
that referenced
this issue
Mar 9, 2021
fmbenhassine
added a commit
that referenced
this issue
Mar 9, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
for: backport-to-4.2.x
Issues that will be back-ported to the 4.2.x line
in: infrastructure
related-to: item-readers-writers
type: bug
I noticed the kafkaItemWriter calls sendDefault (an asynchronous call) without checking the future returned by the call to confirm the data was actually sent. This seems bad to me. I would think it should call flush on the template after the batch is written and then check all the futures to confirm nothing went wrong.
The text was updated successfully, but these errors were encountered: