Les peticions Java concurrents poden compartir paràmetres de proxy incorrectes

Manteniu les peticions Java concurrents a les rutes previstes sense canviar la configuració de proxy compartida de la JVM.

Un fil estableix una propietat de proxy, fa una petició i restaura el valor antic. Un altre fil fa el mateix amb un proxy diferent. El codi sembla ordenat llegit de dalt a baix, però tots dos fils estan canviant estat compartit de la JVM.

System.setProperty() canvia una propietat del sistema per al procés. No adjunta una ruta al fil que l'ha cridat. Una petició concurrent pot veure un valor escrit per a la feina d'una altra persona, i un client existent pot haver capturat ja la seva pròpia configuració.

Feu que la ruta formi part del client

Per al client HTTP de Java, creeu clients amb selectors de proxy deliberats. Manteniu clients separats quan les càrregues de treball requereixin polítiques d'encaminament diferents:

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

Les importacions són java.net, java.net.http i java.time. L'adreça és il·lustrativa; per a proves permeses de rutes públiques, la llista de proxies HTTP proporciona punts finals candidats. Configureu els terminis de les peticions i l'autenticació del proxy per separat segons les necessitats de l'aplicació.

El mètode proxy del constructor registra una elecció a nivell de client. Això fa que la política sigui més fàcil d'inspeccionar que una seqüència d'escriptures globals embolcallades al voltant d'operacions asíncrones.

La configuració global encara té utilitat

Una única política de proxy per a tota la JVM pot ser adequada quan tots els clients participants han de seguir-la. Establiu aquesta política a l'inici de l'aplicació i verifiqueu quines biblioteques la respecten.

Els problemes sorgeixen quan les propietats globals s'utilitzen com a commutador temporal per a peticions individuals. En un servidor, els treballadors en segon pla i les crides de biblioteca poden executar-se concurrentment encara que el vostre mètode sembli síncron. Manteniu l'estat d'encaminament amb el client o connector que posseeix la connexió, perquè una altra petició no el pugui canviar a mig camí.

Articles relacionats