Skip to content

Ktor 3 Don't do reverse lookups of Client and Server Adresses #16391

@jonasplaum

Description

@jonasplaum

Is your feature request related to a problem? Please describe.

While using Ktor 3 we found request to be slow, because there are reverse lookups of the Client / Server IP Adresses.

        at java.net.Inet6AddressImpl.getHostByAddr([email protected]/Native Method)
        at java.net.InetAddress$PlatformResolver.lookupByAddress([email protected]/InetAddress.java:1148)
        at java.net.InetAddress.getHostFromNameService([email protected]/InetAddress.java:772)
        at java.net.InetAddress.getHostName([email protected]/InetAddress.java:728)
        at java.net.InetSocketAddress$InetSocketAddressHolder.getHostName([email protected]/InetSocketAddress.java:83)
        at java.net.InetSocketAddress.getHostName([email protected]/InetSocketAddress.java:360)
        at io.ktor.server.netty.http1.NettyConnectionPoint.getRemoteHost(NettyConnectionPoint.kt:71)
        at io.opentelemetry.instrumentation.ktor.v2_0.common.KtorHttpServerAttributesGetter.getNetworkPeerAddress(KtorHttpServerAttributesGetter.kt:36)
        at io.opentelemetry.instrumentation.ktor.v2_0.common.KtorHttpServerAttributesGetter.getNetworkPeerAddress(KtorHttpServerAttributesGetter.kt:14)
        at io.opentelemetry.instrumentation.api.semconv.http.HttpServerAddressAndPortExtractor.extract(HttpServerAddressAndPortExtractor.java:38)
        at io.opentelemetry.instrumentation.api.semconv.network.internal.ClientAddressAndPortExtractor.extract(ClientAddressAndPortExtractor.java:32)
        at io.opentelemetry.instrumentation.api.semconv.network.internal.AddressAndPortExtractor.extract(AddressAndPortExtractor.java:18)
        at io.opentelemetry.instrumentation.api.semconv.network.internal.InternalClientAttributesExtractor.onStart(InternalClientAttributesExtractor.java:29)
        at io.opentelemetry.instrumentation.api.semconv.http.HttpServerAttributesExtractor.onStart(HttpServerAttributesExtractor.java:82)
        at io.opentelemetry.instrumentation.api.instrumenter.Instrumenter.doStartImpl(Instrumenter.java:196)
        at io.opentelemetry.instrumentation.api.instrumenter.Instrumenter.doStart(Instrumenter.java:174)
        at io.opentelemetry.instrumentation.api.instrumenter.Instrumenter.start(Instrumenter.java:141)
        at io.opentelemetry.instrumentation.api.instrumenter.PropagatingFromUpstreamInstrumenter.start(PropagatingFromUpstreamInstrumenter.java:31)
        at io.opentelemetry.instrumentation.ktor.v2_0.common.internal.KtorServerTracer.start(KtorServerTracer.kt:23)
        at io.opentelemetry.instrumentation.ktor.v2_0.common.internal.KtorServerTelemetryUtil$configureTelemetry$1.invokeSuspend(KtorServerTelemetryUtil.kt:40)
        at io.opentelemetry.instrumentation.ktor.v2_0.common.internal.KtorServerTelemetryUtil$configureTelemetry$1.invoke(KtorServerTelemetryUtil.kt)
        at io.opentelemetry.instrumentation.ktor.v2_0.common.internal.KtorServerTelemetryUtil$configureTelemetry$1.invoke(KtorServerTelemetryUtil.kt)

Describe the solution you'd like

It would be nice to have an option to switch from DNS Resolution caused by InetSocketAddress.getHostName to only logging the real IP Address using InetSocketAddress.getAddress.

Describe alternatives you've considered

Disabeling DNS resolution in this container improves the performance quite a bit, but this is no real solution, as our application needs DNS to talk to other services.

Additional context

No response

Tip

React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requestneeds triageNew issue that requires triage

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions