Les requêtes Java concurrentes peuvent partager de mauvais réglages de proxy

Gardez les requêtes Java concurrentes sur leurs routes prévues sans changer les réglages de proxy partagés de la JVM.

Un thread définit une propriété de proxy, effectue une requête et restaure l'ancienne valeur. Un autre thread fait de même avec un proxy différent. Le code paraît propre lu de haut en bas, mais les deux threads modifient un état partagé de la JVM.

System.setProperty() modifie une propriété système pour le processus. Il n'attache pas une route au thread qui l'a appelé. Une requête concurrente peut observer une valeur écrite pour le travail de quelqu'un d'autre, et un client existant a peut-être déjà capturé sa propre configuration.

Faites de la route une partie du client

Pour le client HTTP de Java, créez des clients avec des sélecteurs de proxy délibérés. Gardez des clients séparés lorsque les charges de travail exigent des politiques de routage distinctes :

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

Les imports sont java.net, java.net.http et java.time. L'adresse est illustrative ; pour des tests autorisés de routes publiques, la liste de proxys HTTP fournit des points de terminaison candidats. Configurez les délais des requêtes et l'authentification du proxy séparément selon les besoins de l'application.

La méthode proxy du constructeur enregistre un choix au niveau du client. Cela rend la politique plus facile à inspecter qu'une séquence d'écritures globales enveloppant des opérations asynchrones.

Les réglages globaux ont encore leur utilité

Une politique de proxy unique à l'échelle de la JVM peut convenir lorsque tous les clients participants sont censés la suivre. Définissez cette politique au démarrage de l'application et vérifiez quelles bibliothèques la respectent.

Les problèmes surviennent lorsque des propriétés globales servent d'interrupteur temporaire pour des requêtes individuelles. Dans un serveur, les workers d'arrière-plan et les appels de bibliothèque peuvent s'exécuter en concurrence même si votre propre méthode semble synchrone. Gardez l'état de routage avec le client ou le connecteur qui possède la connexion, afin qu'une autre requête ne puisse pas le changer en cours de travail.

Articles similaires