Andrea Cosentino created CAMEL-24782:
----------------------------------------

             Summary: camel-kafka - transactional producer can be left 
permanently unusable after a transaction/commit failure (no recreation, commit 
failure not aborted)
                 Key: CAMEL-24782
                 URL: https://issues.apache.org/jira/browse/CAMEL-24782
             Project: Camel
          Issue Type: Bug
          Components: camel-kafka
            Reporter: Andrea Cosentino


h3. Problem
{{KafkaTransactionSynchronization.onDone}} and the transactional producer 
lifecycle can leave the shared {{KafkaProducer}} permanently unusable after a 
transaction error.

* When the exchange failed with a {{KafkaException}}, {{onDone}} calls 
{{kafkaProducer.close()}} on the *shared* producer instance (created once in 
{{KafkaProducer.doStart}}). There is no recreation logic, so every subsequent 
exchange on that route fails because the producer is closed.
* When {{commitTransaction()}} (or {{abortTransaction()}}) itself throws a 
{{KafkaException}}, it is caught and only recorded via 
{{exchange.setException(e)}} - with no {{abortTransaction()}} / {{close()}}. 
Per the Kafka producer contract a failed commit leaves the transactional 
producer in an abortable (or fatal) state that must be aborted or closed before 
reuse, so the *next* exchange's {{beginTransaction()}} fails.

Net effect: a single transaction/commit failure can wedge all subsequent 
transactional exchanges until the route is restarted.

h3. Proposed direction
* Introduce a way to recreate (or lazily re-open) the producer after a fatal 
close, so the route recovers instead of staying broken.
* On a commit failure, move the producer to a well-defined state (abort or 
close+recreate) rather than only setting the exception.
* Add failure-injection tests around commit/abort/close.

Design-first (touches the producer lifecycle and the trust-sensitive 
transactional path); filing to track. Related: CAMEL-24780, CAMEL-24781.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to