Skip to content

Document blocking SPNEGO hostname lookup#2278

Open
pavel-ptashyts wants to merge 1 commit into
AsyncHttpClient:mainfrom
maygemdev:perf/spnego-canonical-hostname
Open

Document blocking SPNEGO hostname lookup#2278
pavel-ptashyts wants to merge 1 commit into
AsyncHttpClient:mainfrom
maygemdev:perf/spnego-canonical-hostname

Conversation

@pavel-ptashyts

Copy link
Copy Markdown
Contributor

Summary

  • document that SPNEGO/Kerberos canonical-hostname resolution performs a blocking JVM lookup
  • identify authentication retries as a path where the lookup can run on a Netty event-loop thread
  • direct users with a known service principal to setServicePrincipalName(...), which avoids hostname canonicalization

Motivation

setUseCanonicalHostname(true) is opt-in, but SpnegoEngine derives the service principal with InetAddress.getByName(...).getCanonicalHostName(). This synchronous lookup can delay unrelated channel work when authentication is retried from an event-loop thread.

Changing or bypassing canonicalization can select a different Kerberos service principal and break authentication. Adding an AsyncHttpClient-specific cache would also introduce hostname freshness semantics separate from the JVM DNS cache, while not eliminating the first blocking lookup. This PR therefore documents the risk and the existing behavior-preserving mitigation without changing runtime semantics.

Validation

  • ./mvnw -B -ntp -pl client -DskipTests -Dgpg.skip=true verify (compilation, Javadocs, and Revapi)

The required JDK 11 ./mvnw clean verify was not run because JDK 11 is not available in the local environment. This documentation-only change does not alter runtime behavior; CI will exercise the supported JDK matrix.

Codex on behalf of Pavel Ptashyts

Canonical-hostname resolution is opt-in but performs a synchronous JVM
lookup while deriving the Kerberos service principal. Authentication
retries can invoke that lookup on a Netty event-loop thread.

Document the blocking behavior and direct users with a known principal
to the existing explicit service-principal setting.

Codex on behalf of Pavel Ptashyts

Co-Authored-By: Codex <codex@openai.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant