Gelyktydige Java-versoeke kan die verkeerde proxy-instellings deel

Een draad stel 'n proxy-eienskap, maak 'n versoek en herstel die ou waarde. 'n Ander draad doen dieselfde met 'n ander proxy. Die kode lyk netjies van bo na onder, maar albei drade verander gedeelde JVM-toestand.

System.setProperty() verander 'n stelsel-eienskap vir die proses. Dit heg nie 'n roete aan die draad wat dit geroep het nie. 'n Gelyktydige versoek kan 'n waarde sien wat vir iemand anders se werk geskryf is, en 'n bestaande kliënt het dalk al sy eie konfigurasie vasgevang.

Maak die roete deel van die kliënt

Vir Java se HTTP-kliënt, skep kliënte met doelbewuste proxy-keuses. Hou aparte kliënte wanneer werkladinge verskillende roetebeleid vereis:

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

Die invoere is java.net, java.net.http, en java.time. Die adres is illustratief; vir toegelate openbare-roete-toetse verskaf die HTTP-proxylys kandidaat-eindpunte. Stel versoek-sperdatums en proxy-verifikasie afsonderlik volgens die toepassing se behoeftes.

Die bouer se proxy-metode teken 'n keuse op kliëntvlak aan. Dit maak die beleid makliker om te inspekteer as 'n reeks globale skryfhandelinge rondom asinchrone bewerkings.

Globale instellings het steeds 'n nut

'n Enkele JVM-wye proxy-beleid kan gepas wees wanneer elke deelnemende kliënt bedoel is om dit te volg. Stel daardie beleid by toepassingbegin en verifieer watter biblioteke dit eerbiedig.

Probleme ontstaan wanneer globale eienskappe as 'n tydelike skakelaar vir individuele versoeke gebruik word. In 'n bediener kan agtergrondwerkers en biblioteekoproepe gelyktydig loop selfs al lyk jou eie metode sinchronies. Hou roetetoestand by die kliënt of verbinding wat die verbinding besit, sodat 'n ander versoek dit nie halfpad deur die werk kan verander nie.