apalan60 commented on PR #19482:
URL: https://github.com/apache/kafka/pull/19482#issuecomment-2868724157
> @apalan60 thanks for this patch. Is it possible to replace
`ProducerStateManagerConfig` by `TransactionLogConfig`? In the
`DynamicProducerStateManagerConfig` we create `TransactionLogConfig` to update
`ProducerStateManagerConfig`
@chia7712
Thanks for the review!
It seems that `ProducerStateManagerConfig` is just a wrapper around
`TransactionLogConfig`. In current flow, clients update dynamic broker configs
by:
1. Constructing a new `TransactionLogConfig`
2. Passing it into `ProducerStateManagerConfig`
If standardize on using `TransactionLogConfig` directly, it could eliminate
that extra conversion step.
---
I tried refactoring this way, but I’ve hit a circular-dependency problem:
- **Module structure**
transaction‑coordinator → coordinator‑common → storage
- [transaction‑coordinator →
coordinator‑common](https://github.com/apache/kafka/blob/bf05d2c91439ad4218f30343215a7ce16b0dc2b4/transaction-coordinator/src/main/java/org/apache/kafka/coordinator/transaction/TransactionCoordinatorRecordSerde.java#L21)
- [coordinator‑common →
storage](https://github.com/apache/kafka/blob/6e26ec06bb895ff236cf1a402827d95e8d3c8c4d/coordinator-common/src/main/java/org/apache/kafka/coordinator/common/runtime/CoordinatorRuntime.java#L46-L47)
- `storage.internals.log.UnifiedLog` currently depends on
`ProducerStateManagerConfig`.
If it were to call `TransactionLogConfig`, then **storage** would need to
depend on **transaction‑coordinator**, creating a cycle.
I’m not sure if it’s appropriate to modify the module dependencies directly.
Please let me know if I’ve misunderstood anything or if you have any
suggestions for resolving the dependency cycle.
--
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: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
