Один потік задає властивість проксі, виконує запит і відновлює старе значення. Інший потік робить те саме з іншим проксі. Код виглядає охайно при читанні згори донизу, але обидва потоки змінюють спільний стан JVM.

System.setProperty() змінює системну властивість для процесу. Він не прикріплює маршрут до потоку, який його викликав. Паралельний запит може побачити значення, записане для чужої роботи, а наявний клієнт може вже зафіксувати власну конфігурацію.

Зробіть маршрут частиною клієнта

Для HTTP-клієнта Java створюйте клієнтів із навмисними селекторами проксі. Тримайте окремих клієнтів, коли робочі навантаження вимагають різних політик маршрутизації:

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

Імпорти — java.net, java.net.http і java.time. Адреса ілюстративна; для дозволених тестів публічних маршрутів список HTTP-проксі надає кандидатні кінцеві точки. Налаштуйте терміни запитів і автентифікацію проксі окремо відповідно до потреб застосунку.

метод proxy конструктора фіксує вибір на рівні клієнта. Це робить політику легшою для перевірки, ніж послідовність глобальних записів, обгорнутих навколо асинхронних операцій.

Глобальні налаштування все ще потрібні

Єдина політика проксі для всієї JVM може бути доречною, коли кожен задіяний клієнт має її дотримуватися. Задайте цю політику під час запуску застосунку й перевірте, які бібліотеки її поважають.

Проблеми виникають, коли глобальні властивості використовують як тимчасовий перемикач для окремих запитів. На сервері фонові працівники та виклики бібліотек можуть виконуватися паралельно, навіть якщо ваш метод здається синхронним. Тримайте стан маршрутизації при клієнті або з'єднувачі, який володіє з'єднанням, щоб інший запит не міг змінити його посеред роботи.

Схожі статті