oscerd opened a new pull request, #27186:
URL: https://github.com/apache/camel/pull/27186
## Problem
`KafkaTransactionSynchronization.onDone` left the **shared** producer
unusable after a failed
transaction, wedging the route:
- On a `KafkaException` it `close()`d the shared producer with **no
recreation**.
`KafkaProducer.kafkaProducer` kept pointing at the closed instance, so
every later exchange failed to
begin or send a transaction.
- A failed **commit** (`catch (KafkaException)`) only recorded the
exception, leaving the transaction
**open**, so the next `beginTransaction()` failed.
- The close heuristic was too broad: *any* `KafkaException` closed the
producer, even a downstream
failure that an abort would have recovered from.
## Fix
Follows Kafka's documented transactional-producer pattern:
- **Classify** fatal errors (`ProducerFencedException`,
`OutOfOrderSequenceException`,
`AuthorizationException`) from abortable ones.
- **Fatal** → close the producer and mark it for recreation. `KafkaProducer`
rebuilds it **lazily** on
the next transactional send (thread-safe, re-initialising transactions and
re-setting the transactional
id), so the route recovers instead of staying wedged on a dead producer.
- **Abortable** → `abortTransaction()` so the shared producer stays usable;
if the abort itself fails,
close + recreate.
- A **failed commit** now goes through the same recovery (abort, or
close+recreate when fatal) instead
of leaving the transaction open.
Recreation is lazy (done on the next send, not from the Kafka callback
thread) and guarded, so
concurrent callers rebuild once.
## Tests
- `KafkaTransactionSynchronizationTest` (new): fatal→close+mark,
non-fatal→abort, rollback-only→abort,
commit success, commit-fatal→close+mark, commit-abortable→abort,
failed-abort→close+mark.
- `KafkaProducerTest.transactionalProducerIsRecreatedAfterAFatalError`:
after a fatal error marks the
producer closed, the next transaction rebuilds it via the client factory
and re-inits transactions.
Revert-to-red verified (disabling recreation fails the recreation test;
gutting the commit recovery
fails the two commit tests). `mvn clean test -pl components/camel-kafka`:
**217 run, 0 failures,
0 errors, 1 skipped**. No metadata change → no catalog/DSL regeneration.
Related: CAMEL-24780 (transaction begin), CAMEL-24783 (async batch dispatch,
#27142).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]