014 - Proposal to refactor frontend handler and centralize session context#88
Open
hrishabhg wants to merge 1 commit intokroxylicious:mainfrom
Conversation
Refactor frontend handler architecture to improve separation of concerns, introduce a centralized session context, fix HAProxy message memory leak, and simplify the state machine by eliminating unnecessary states. Signed-off-by: Hrishabh Gupta <hgupta@confluent.io>
hrishabhg
changed the title
tombentley
reviewed
Feb 27, 2026
Member
tombentley
left a comment
tombentley
left a comment
There was a problem hiding this comment.
This seems mostly reasonable. Thanks.
As a more general point, please don't feel the need to write a proposal for a refactoring which doesn't touch public APIs (which is the case here). A proposal can serve as a place to discuss a larger change without actually having to implement it in its entirety so you can open a PR for it.
I've also been thinking about a few other changes which would function as either clean up of accumulated tech debt (which we should do anyway) or enablers for routing-like functionality:
- Currently we initialize the backend pipeline in the frontend handler. That seems ripe for moving to the backend handler itself. I hope to open a PR for this next week.
- I think we should be able to factor out some kind of abstraction for tracking reasons and managing the
autoReadflag which we use for backpressure. I hope to open a PR for this next week. - I don't think the PCSM can really survive in its current form if we want to support routing. It seems to me there's a state machine associated with the frontend (tracking the building up of your
ClientSession), and one associated with a backend. A router could only forward (most) requests to a backend once we have TCP, TLS?, SASL?. At that point the Route is in theFORWARDINGstate, and requests can pass down the pipeline associated with that Route. Does this fit whatever thoughts you might have had about routing?
Comment on lines
+18
to
+20
| ### HAProxy message memory leak | ||
|
|
||
| `HAProxyMessage` implements Netty's `ReferenceCounted` interface but is never released. The message is intercepted in `HAProxyMessageHandler`, passed to the state machine, stored in state records, but never has `release()` called. This causes a memory leak. |
Member
There was a problem hiding this comment.
This seems like low-hanging fruit which doesn't depend on the rest. We should just fix it. Would you be willing to open a PR for this?
Author
There was a problem hiding this comment.
I will take that up soon with the HAProxyMessage fix.
k-wall
added a commit
to k-wall/design
that referenced
this pull request
Apr 9, 2026
This introduces a proposal index (README.md) for the proposals directory to solve the problem of colliding proposal numbers. Currently, multiple open PRs have chosen proposal numbers that conflict with already-merged proposals. This creates confusion and makes it difficult to maintain stable identifiers for proposals - which is essential for productive discussion on the mailing list. The new process: 1. Authors create proposals with temporary filenames (nnn-*) 2. A separate PR to this README allocates the next sequential number 3. Authors rename their proposal once the number is allocated 4. The index is updated again when proposals are accepted This ensures: - Proposal numbers are allocated chronologically - No number collisions occur - Each proposal gets a stable identifier before mailing list discussion - Clear visibility of open vs. accepted proposals Current collisions resolved by this index: - PR kroxylicious#70, kroxylicious#82, kroxylicious#83, kroxylicious#88, kroxylicious#89 all have numbers conflicting with accepted proposals and have been allocated new sequential numbers (016-024) Assisted-By: Claude Sonnet 4.5 <noreply@anthropic.com>
k-wall
added a commit
to k-wall/design
that referenced
this pull request
Apr 9, 2026
This introduces a proposal index (README.md) for the proposals directory to solve the problem of colliding proposal numbers. Currently, multiple open PRs have chosen proposal numbers that conflict with already-merged proposals. This creates confusion and makes it difficult to maintain stable identifiers for proposals - which is essential for productive discussion on the mailing list. The new process: 1. Authors create proposals with temporary filenames (nnn-*) 2. A separate PR to this README allocates the next sequential number 3. Authors rename their proposal once the number is allocated 4. The index is updated again when proposals are accepted This ensures: - Proposal numbers are allocated chronologically - No number collisions occur - Each proposal gets a stable identifier before mailing list discussion - Clear visibility of open vs. accepted proposals Current collisions resolved by this index: - PR kroxylicious#70, kroxylicious#82, kroxylicious#83, kroxylicious#88, kroxylicious#89 all have numbers conflicting with accepted proposals and have been allocated new sequential numbers (016-024) Assisted-By: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Keith Wall <kwall@apache.org>
k-wall
added a commit
to k-wall/design
that referenced
this pull request
Apr 9, 2026
This introduces a proposal index (README.md) for the proposals directory to solve the problem of colliding proposal numbers. Currently, multiple open PRs have chosen proposal numbers that conflict with already-merged proposals. This creates confusion and makes it difficult to maintain stable identifiers for proposals - which is essential for productive discussion on the mailing list. The new process: 1. Authors create proposals with temporary filenames (nnn-*) 2. A separate PR to this README allocates the next sequential number 3. Authors rename their proposal once the number is allocated 4. The index is updated again when proposals are accepted This ensures: - Proposal numbers are allocated chronologically - No number collisions occur - Each proposal gets a stable identifier before mailing list discussion - Clear visibility of open vs. accepted proposals Current collisions resolved by this index: - PR kroxylicious#70, kroxylicious#82, kroxylicious#83, kroxylicious#88, kroxylicious#89 all have numbers conflicting with accepted proposals and have been allocated new sequential numbers (016-024) Assisted-By: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: Keith Wall <kwall@apache.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refactor frontend handler architecture to improve separation of concerns, introduce a centralized session context, fix HAProxy message memory leak, and simplify the state machine by eliminating unnecessary states.