[
https://issues.apache.org/jira/browse/KAFKA-20644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Zeger updated KAFKA-20644:
--------------------------------
Description:
The Connect REST server supports separating admin endpoints (/loggers, etc.)
onto a different listener via admin.listeners. The intended cases:
> admin.listeners not set (null) → admin resources go on the main listeners.
> admin.listeners set to empty list → admin resources disabled.
> admin.listeners set to different values from listeners → admin resources go
> on a separate connector.
The TODOs flag the missing case:
> admin.listeners set to the same values as listeners.
Today the code enters the else \{ else{ ... }} branch, creates a brand-new
ResourceConfig for admin resources, and proceeds - but the new ResourceConfig
is bound to a Jetty connector that won’t be created (because listeners and
admin.listeners resolve to the same Jetty connector). The admin resources
become orphaned. Operators see /loggers return 404 on the listener they
configured for both regular and admin traffic.
Reproduction:
{code:java}
# connect-distributed.properties
listeners=http://0.0.0.0:8083
admin.listeners=http://0.0.0.0:8083 {code}
It’s a low-stakes but deeply confusing failure mode.
The operator: Reads docs that say admin.listeners exposes admin resources on a
separate listener. Configures them to the same value (e.g. because they want
the admin features but don’t want a separate port). Hits 404 with no clear
error.
Either case should be handled gracefully: If the user wants admin resources on
the same port, set admin.listeners to null (or to the same string and have the
code recognise it). The current code’s silent orphaning is the worst possible
outcome.
*Proposed fix*
# Option A: treat matching listeners as null
# Option B: fail fast
*KIP needed?*
No - edge case for already broken flow by a design
was:
The Connect REST server supports separating admin endpoints (/loggers, etc.)
onto a different listener via admin.listeners. The intended cases:
> admin.listeners not set (null) → admin resources go on the main listeners.
> admin.listeners set to empty list → admin resources disabled.
> admin.listeners set to different values from listeners → admin resources go
> on a separate connector.
The TODOs flag the missing case:
> admin.listeners set to the same values as listeners.
Today the code enters the else \{ else{ ... }} branch, creates a brand-new
ResourceConfig for admin resources, and proceeds - but the new ResourceConfig
is bound to a Jetty connector that won’t be created (because listeners and
admin.listeners resolve to the same Jetty connector). The admin resources
become orphaned. Operators see /loggers return 404 on the listener they
configured for both regular and admin traffic.
Reproduction:
{code:java}
# connect-distributed.properties
listeners=http://0.0.0.0:8083
admin.listeners=http://0.0.0.0:8083 {code}
It’s a low-stakes but deeply confusing failure mode.
The operator: Reads docs that say admin.listeners exposes admin resources on a
separate listener. Configures them to the same value (e.g. because they want
the admin features but don’t want a separate port). Hits 404 with no clear
error.
Either case should be handled gracefully: If the user wants admin resources on
the same port, set admin.listeners to null (or to the same string and have the
code recognise it). The current code’s silent orphaning is the worst possible
outcome.
*Proposed fix*
Four changes:
# Option A: treat matching listeners as null
# Option B: fail fast
*KIP needed?*
No - edge case for already broken flow by a design
> Connect’s RestServer assumes admin.listeners differ from listeners, silently
> orphaning admin resources when they match
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: KAFKA-20644
> URL: https://issues.apache.org/jira/browse/KAFKA-20644
> Project: Kafka
> Issue Type: Bug
> Reporter: Pavel Zeger
> Priority: Major
>
> The Connect REST server supports separating admin endpoints (/loggers, etc.)
> onto a different listener via admin.listeners. The intended cases:
> > admin.listeners not set (null) → admin resources go on the main listeners.
> > admin.listeners set to empty list → admin resources disabled.
> > admin.listeners set to different values from listeners → admin resources go
> > on a separate connector.
> The TODOs flag the missing case:
> > admin.listeners set to the same values as listeners.
> Today the code enters the else \{ else{ ... }} branch, creates a brand-new
> ResourceConfig for admin resources, and proceeds - but the new ResourceConfig
> is bound to a Jetty connector that won’t be created (because listeners and
> admin.listeners resolve to the same Jetty connector). The admin resources
> become orphaned. Operators see /loggers return 404 on the listener they
> configured for both regular and admin traffic.
>
> Reproduction:
> {code:java}
> # connect-distributed.properties
> listeners=http://0.0.0.0:8083
> admin.listeners=http://0.0.0.0:8083 {code}
> It’s a low-stakes but deeply confusing failure mode.
> The operator: Reads docs that say admin.listeners exposes admin resources on
> a separate listener. Configures them to the same value (e.g. because they
> want the admin features but don’t want a separate port). Hits 404 with no
> clear error.
> Either case should be handled gracefully: If the user wants admin resources
> on the same port, set admin.listeners to null (or to the same string and have
> the code recognise it). The current code’s silent orphaning is the worst
> possible outcome.
> *Proposed fix*
> # Option A: treat matching listeners as null
> # Option B: fail fast
> *KIP needed?*
> No - edge case for already broken flow by a design
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
