Samtidiga Java-förfrågningar kan dela fel proxyinställningar
Håll samtidiga Java-förfrågningar på sina avsedda rutter utan att byta delade proxyinställningar i JVM:en.
En tråd sätter en proxyegenskap, gör en förfrågan och återställer det gamla värdet. En annan tråd gör samma sak med en annan proxy. Koden ser prydlig ut när man läser uppifrån och ned, men båda trådarna ändrar delat JVM-tillstånd.
System.setProperty() ändrar en systemegenskap för processen. Det knyter inte en rutt till tråden som anropade det. En samtidig förfrågan kan se ett värde som skrivits för någon annans arbete, och en befintlig klient kan redan ha fångat sin egen konfiguration.
Gör rutten till en del av klienten
För Javas HTTP-klient skapar du klienter med medvetna proxyväljare. Håll separata klienter när arbetsbelastningar kräver olika routningsprinciper:
HttpClient client = HttpClient.newBuilder()
.proxy(ProxySelector.of(
new InetSocketAddress("203.0.113.10", 8080)))
.connectTimeout(Duration.ofSeconds(5))
.build();
Importerna är java.net, java.net.http och java.time. Adressen är illustrativ; för tillåtna tester av offentliga rutter tillhandahåller listan över HTTP-proxyer kandidatslutpunkter. Konfigurera förfrågningsdeadlines och proxyautentisering separat efter programmets behov.
byggarens proxy-metod registrerar ett val på klientnivå. Det gör principen lättare att granska än en sekvens globala skrivningar inlindade kring asynkrona operationer.
Globala inställningar har fortfarande en användning
En enda JVM-omfattande proxyprincip kan vara lämplig när varje deltagande klient är avsedd att följa den. Sätt den principen vid programstart och verifiera vilka bibliotek som följer den.
Problem uppstår när globala egenskaper används som en tillfällig omkopplare för enskilda förfrågningar. I en server kan bakgrundsarbetare och biblioteksanrop köras samtidigt även om din egen metod verkar synkron. Håll routningstillståndet hos den klient eller anslutningspunkt som äger anslutningen, så att en annan förfrågan inte kan ändra det mitt i arbetet.