appchemist commented on PR #16043:
URL: https://github.com/apache/kafka/pull/16043#issuecomment-2128669455
> i really want to keep the network client delegate to just interfacing with
the network client, so i wonder if it would be a better design to handle the
metadata error in a separated module. wdyt?
I think there are pros and cons to each approach.
Current Patch:
Pros:
- Simple
- Enhanced code comprehension: Similar to legacy code
Cons:
- Violates SRP
- `NetworkClientDelegate` will also have non-interfacing behaviour.
Separated Modules(`PropagateErrorMetadataUpdater` in
https://github.com/apache/kafka/pull/15961):
Pros:
- Adheres to SOLID principles
Cons:
- Can be more complex
- Act on the client network layer.
I'm having difficulty determining which aspect should be prioritized.
Like you said, it made me think about design as a priority.
Our goal is to propagate metadata errors from the background thread to the
foreground thread at the appropriate time.
`MetadataUpdater` seems to play a "role" in handling metadata changes,
making it a suitable candidate for propagating metadata errors.
`PropagateErrorMetadataUpdater` acts as a proxy for handling metadata errors.
We've taken an approach that extends metadata error handling without
modifying `NetworkClient`'s logic.
What do you think?
You can see the approach in https://github.com/apache/kafka/pull/15961 and I
would appreciate your review
--
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
