Samtidige Java-anmodninger kan dele de forkerte proxyindstillinger

Én tråd sætter en proxyegenskab, sender en anmodning og gendanner den gamle værdi. En anden tråd gør det samme med en anden proxy. Koden ser pæn ud, når den læses ovenfra og ned, men begge tråde ændrer delt JVM-tilstand.

System.setProperty() ændrer en systemegenskab for processen. Det knytter ikke en rute til den tråd, der kaldte det. En samtidig anmodning kan se en værdi skrevet for en andens arbejde, og en eksisterende klient kan allerede have opsnappet sin egen konfiguration.

Gør ruten til en del af klienten

Til Javas HTTP-klient skal du oprette klienter med bevidste proxyvælgere. Hold separate klienter, når arbejdsbyrder kræver forskellige routingpolitikker:

HttpClient client = HttpClient.newBuilder()
    .proxy(ProxySelector.of(
        new InetSocketAddress("203.0.113.10", 8080)))
    .connectTimeout(Duration.ofSeconds(5))
    .build();

Importerne er java.net, java.net.http og java.time. Adressen er illustrativ; til tilladte test af offentlige ruter leverer HTTP-proxylisten kandidatendepunkter. Konfigurer anmodningsfrister og proxygodkendelse separat efter applikationens behov.

Builderens proxy-metode registrerer et valg på klientniveau. Det gør politikken lettere at inspicere end en sekvens af globale skrivninger pakket omkring asynkrone operationer.

Globale indstillinger har stadig en anvendelse

Én JVM-dækkende proxypolitik kan være passende, når alle deltagende klienter skal følge den. Angiv politikken ved applikationsstart, og bekræft, hvilke biblioteker der respekterer den.

Problemer opstår, når globale egenskaber bruges som en midlertidig kontakt til enkelte anmodninger. På en server kan baggrundsarbejdere og bibliotekskald køre samtidigt, selv om din egen metode ser synkron ud. Hold routingtilstand hos den klient eller connector, der ejer forbindelsen, så en anden anmodning ikke kan ændre den midt i jobbet.