Samtidige Java-forespørsler kan dele feil proxyinnstillinger

Én tråd setter en proxy-egenskap, sender en forespørsel og gjenoppretter den gamle verdien. En annen tråd gjør det samme med en annen proxy. Koden ser ryddig ut når den leses ovenfra og ned, men begge trådene endrer delt JVM-tilstand.

System.setProperty() endrer en systemegenskap for prosessen. Det knytter ikke en rute til tråden som kalte det. En samtidig forespørsel kan se en verdi som er skrevet for andres arbeid, og en eksisterende klient kan allerede ha fanget opp sin egen konfigurasjon.

Gjør ruten til en del av klienten

For Java sin HTTP-klient, opprett klienter med bevisste proxy-velgere. Hold separate klienter når arbeidsbelastninger krever ulike rutingspolicyer:

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

Importene er java.net, java.net.http og java.time. Adressen er illustrativ; for tillatte offentlige rute tester leverer HTTP-proxylisten kandidat-endepunkter. Konfigurer forespørselsfrister og proxy-autentisering separat etter applikasjonens behov.

Byggerens proxy-metode registrerer et valg på klientnivå. Det gjør policyen enklere å inspisere enn en sekvens med globale skrivinger rundt asynkrone operasjoner.

Globale innstillinger har fortsatt en nytte

Én proxy-policy for hele JVM-en kan være passende når hver deltakende klient er ment å følge den. Sett den policyen ved oppstart av applikasjonen og verifiser hvilke biblioteker som respekterer den.

Problemer oppstår når globale egenskaper brukes som en midlertidig bryter for enkelte forespørsler. I en server kan bakgrunnsarbeidere og bibliotekkall kjøre samtidig selv om metoden din ser synkron ut. Hold rutetilstanden hos klienten eller koblingen som eier forbindelsen, slik at en annen forespørsel ikke kan endre den midt i jobben.