apache/arrow-java

Flight-SQL JDBC driver ignores JVM proxy settings

Aperta

#577 aperta il 30 gen 2025

 (8 commenti) (0 reazioni) (1 assegnatario)Java (132 fork)auto 404
Type: enhancementhelp wanted

Metriche repository

Star
 (89 stelle)
Metriche merge PR
 (Metriche PR in attesa)

Descrizione

Describe the enhancement requested

Hi, I was making some tests for checking the support of proxies with the Flight-SQL JDBC driver.

GRPC supports the JVM properties for indicating the default http proxy to use. Nevertheless, I tested with Flight-SQL JDBC driver without luck. The driver is ignoring them. I mean these ones: -Dhttps.proxyHost=<host> -Dhttps.proxyPort=<port>

Checking the reason, I arrived to these lines where the Netty channel is opened: https://github.com/apache/arrow-java/blob/bd2173c59c52983a9e1a6cadffb8345294960949/flight/flight-core/src/main/java/org/apache/arrow/flight/FlightClient.java#L854-L862

Using method io.grpc.netty.NettyChannelBuilder#forAddress(java.net.SocketAddress) makes GRPC to create the channel using a direct connection to the host:port specified at connection uri, ignoring the proxy. This happens on this code from ManagedChannelImplBuilder

  public ManagedChannelImplBuilder(SocketAddress directServerAddress, String authority,
      @Nullable ChannelCredentials channelCreds, @Nullable CallCredentials callCreds,
      ClientTransportFactoryBuilder clientTransportFactoryBuilder,
      @Nullable ChannelBuilderDefaultPortProvider channelBuilderDefaultPortProvider) {
    this.target = makeTargetStringForDirectAddress(directServerAddress);
    this.channelCredentials = channelCreds;
    this.callCredentials = callCreds;

I am not sure if there is a special reason for not opening the connection with the host and port values, instead of the java.net.SocketAddress:

builder = NettyChannelBuilder.forAddress(
                    location.getUri().getHost(), location.getUri().getPort());

But opening the channel in the previous way makes GRPC to follow the specified proxy at JVM properties. -Dhttps.proxyHost=<host> -Dhttps.proxyPort=<port>

Could this be a valid enhancement request?

Guida contributor