Unbounded KafkaTemplate.send().get() in KpiProducer — potential blocking under broker latency

[Joaquinriosheredia]

Summary

While reviewing Kafka producer usage patterns in this module, I noticed that
KpiProducer calls KafkaTemplate.send().get() without a timeout. This can
cause the calling thread to block indefinitely if the broker is slow,
unreachable, or the topic is unavailable. I haven't seen this cause a
concrete failure in this repo — I'm flagging it as a possible hardening
opportunity, not reporting an incident.

Location

spring-kafka-4/src/main/java/com/baeldung/kafka/batch/KpiProducer.java:17

public void sendMessage(String topic, String message) throws ExecutionException, InterruptedException {
    kafkaTemplate.send(topic, message).get();   // line 17 — no timeout
    this.kafkaTemplate.flush();
}

Why this can matter

Future.get() with no arguments blocks the calling thread until the send
completes, with no upper bound. If the broker is unreachable, the partition
leader is unavailable, or there's elevated network latency, this call can
hang far longer than a caller would expect. If sendMessage is ever invoked
from a request-handling thread or a bounded thread pool, that shape can lead
to thread starvation under load.

The usual mitigation is Future.get(timeout, TimeUnit), so a slow or
unavailable broker surfaces as a handled TimeoutException instead of an
unbounded block.

What I checked before opening this

• I searched the repo and found KpiProducer is only referenced by
  KafkaBatchProcessingLiveTest and KafkaNoBatchLiveTest, both of which
  exercise it against an EmbeddedKafkaBroker in tests.
• I did not find a production/application caller of
  KpiProducer.sendMessage() anywhere in this repo. So I can't say this
  pattern has caused (or would currently cause) an actual problem here —
  this is a potential-risk report, not a report of observed behavior.
• If this class is intentionally a minimal/naive example (e.g., for later
  contrast with a batching or async approach elsewhere in this module), this
  issue may simply not apply — feel free to close it in that case.

Suggested change (optional)

kafkaTemplate.send(topic, message).get(5, TimeUnit.SECONDS);

(with whatever timeout/exception-handling strategy fits this tutorial's
purpose).

Additional context

For what it's worth, I've applied this same fix shape (bounded
.get(timeout, TimeUnit) instead of unbounded .get()) in a reproducible
production-pattern lab I maintain:
https://github.com/Joaquinriosheredia/Java-Production-Labs — see
commit 01cee184.
I'm sharing it only as an illustration of what the change looks like, not as
evidence that this repository has the same issue — entirely your call
whether it's worth adopting here.

Thanks for maintaining this repo — happy to close this out or help however's
useful if it turns out not to be relevant.

[ulisseslima]

Hey, @Joaquinriosheredia.

Were you following a specific article when you bumped into this? If so, please include the link here.

[Joaquinriosheredia]

Hey @ulisseslima — no, not from an article. This came out of a static-analysis CLI I'm building (java-vibe-guard) that flags unbounded Future.get() on Kafka sends; I ran it against a batch of public repos, this one included, as part of testing the pipeline against real code, and KpiProducer.java:17 came up as a hit.

I didn't take the scanner's output at face value, though — I read KpiProducer itself, traced its only callers (KafkaBatchProcessingLiveTest / KafkaNoBatchLiveTest, both test-only against an embedded broker), and confirmed there's no production caller in this repo before writing it up, which is why I framed it as a potential-risk report rather than an observed-failure one. The scanner just pointed me at the line; the caller analysis in the issue is manual.

Happy to close it if you'd rather not carry the change — no pressure either way.