Samtempaj Java-petoj povas kunhavi malĝustajn prokurilajn agordojn

Unu fadeno agordas prokurilan econ, faras peton kaj restarigas la malnovan valoron. Alia fadeno faras la samon kun malsama prokurilo. La kodo aspektas ordema legite de supre malsupren, sed ambaŭ fadenoj ŝanĝas kunhavatan JVM-staton.

System.setProperty() ŝanĝas sistem-econ por la procezo. Ĝi ne ligas vojon al la fadeno, kiu ĝin vokis. Samtempa peto povas vidi valoron skribitan por la laboro de iu alia, kaj ekzistanta kliento eble jam kaptis sian propran agordon.

Faru la vojon parto de la kliento

Por la HTTP-kliento de Java, kreu klientojn kun konsciaj prokuril-elektiloj. Tenu apartajn klientojn, kiam laborŝarĝoj postulas malsamajn enkursigajn politikojn:

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

La importoj estas java.net, java.net.http kaj java.time. La adreso estas ilustra; por permesitaj testoj de publikaj vojoj, la listo de HTTP-prokuriloj provizas kandidatajn finpunktojn. Agordu petajn limdatojn kaj prokurilan aŭtentikigon aparte laŭ la bezonoj de la aplikaĵo.

La prokurila metodo de la konstruilo registras elekton je klienta nivelo. Tio faciligas la kontroladon de la politiko ol sinsekvo de tutmondaj skriboj volvitaj ĉirkaŭ nesinkronaj operacioj.

Tutmondaj agordoj ankoraŭ utilas

Ununura tut-JVM-a prokurila politiko povas taŭgi, kiam ĉiuj partoprenantaj klientoj devas sekvi ĝin. Agordu tiun politikon ĉe la ekfunkciigo de la aplikaĵo kaj kontrolu, kiuj bibliotekoj respektas ĝin.

Problemoj aperas, kiam tutmondaj ecoj uziĝas kiel provizora ŝaltilo por unuopaj petoj. En servilo, fonsaj laborantoj kaj bibliotekaj vokoj povas funkcii samtempe eĉ se via propra metodo ŝajnas sinkrona. Tenu la enkursigan staton ĉe la kliento aŭ konektilo, kiu posedas la konekton, por ke alia peto ne povu ŝanĝi ĝin duonvoje.