philipnee commented on PR #14690:
URL: https://github.com/apache/kafka/pull/14690#issuecomment-1793014796
Hi @lianetm and @kirktrue @dajac - Thank you for putting this PR out, much
appreciate for the effort. I have concern about the extensive use of callback
here because it is kind of against the original design goal, i.e. making
background thread operate in a linear fashion. With the main thread involved,
I'm also seeing the risk of multithreading access to the background thread.
Here are my questions:
Do we need to use the completable future to facilitate the rebalance
callback completion cycle? My original thought was to use Queues to relay the
callback invocation and completion, because I see that in some cases, it is
unclear to me which thread is completing which callback. To avoid the
confusion all together, I think we should try to use the queue as much as
possible. Also, it make the program to operate more linearly.
If we don't use completable future for the callback, we just need to do two
things
1. if the listen isPresent, we just need to enqueue an event to the
backgroundEventQueue and wait for the consumer to poll. Once the main thread
completes the callback, it enqueues an ack event for background thread to
consume, to transition to the next state.
2. if the listener is not presented. Then we directly invoke the next state
transition method.
Also, it seems like
`reconciliationResult.whenComplete((result, error) -> {`
this is completed by the application thread no? I think we really want the
background thread to perform in a single-threading fashion, I'm afraid using
callback might result in a some sort of race condition.
--
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
