Sanidi chaneli ya gRPC ya Pub/Sub Java kwa HTTP CONNECT

Tumia mtoa chaneli wa mteja uliozalishwa wakati muunganisho wa Pub/Sub Java gRPC unahitaji proksi ya HTTP CONNECT. Mpangilio wa kawaida wa URLConnection hauanzishi usanidi huu wa chaneli.

Kwa mteja wa topic-admin:

var channelProvider = TopicAdminSettings
    .defaultGrpcTransportProviderBuilder()
    .setChannelConfigurator(channel -> channel.proxyDetector(target ->
        HttpConnectProxiedSocketAddress.newBuilder()
            .setProxyAddress(new InetSocketAddress("proxy.example", 8080))
            .setTargetAddress((InetSocketAddress) target)
            .setUsername(proxyUser)
            .setPassword(proxyPassword)
            .build()))
    .build();

var settings = TopicAdminSettings.newBuilder()
    .setTransportChannelProvider(channelProvider)
    .build();
try (TopicAdminClient client = TopicAdminClient.create(settings)) {
    // Perform the application's intended topic-admin operation here.
}

TopicAdminClient na TopicAdminSettings ni madaraja ya Pub/Sub v1; HttpConnectProxiedSocketAddress hutoka io.grpc na InetSocketAddress hutoka java.net. Mfano unadhania lengo la kawaida la anwani ya intaneti linalotumiwa na chaneli hii.

Kigunduzi hurudisha anwani ya muunganisho wa proksi pamoja na lengo la awali. Kijenzi cha gRPC kinahitaji anwani ya proksi itatuliwe. Acha kituo cha mwisho cha huduma kiwe Pub/Sub: kuibadilisha na jina la mwenyeji wa proksi kutapoteza lengo la huduma na utambulisho wa TLS uliokusudiwa.

Ondoa miito ya jina la mtumiaji/nenosiri kwa proksi isiyo na uthibitishaji; wagombea wa HTTP wa umma wanapatikana katika orodha ya proksi za HTTP. Miito hiyo ni kiolesura cha vitambulisho vya HTTP CONNECT, si SOCKS au utekelezaji wa jumla wa NTLM.

Ikiwa hitilafu itatokea kabla ya operesheni ya gRPC wakati vitambulisho vilivyoundwa kwa kujitegemea vinapata tokeni, chunguza njia ya HTTP ya vitambulisho hivyo. Iko nje ya mtoa chaneli aliyeonyeshwa hapa.