Едновременните Java заявки могат да споделят грешни прокси настройки

Една нишка задава свойство за прокси, прави заявка и възстановява старата стойност. Друга нишка прави същото с различно прокси. Кодът изглежда подреден при четене отгоре надолу, но и двете нишки променят споделено състояние на 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 прокси предоставя кандидати за крайни точки. Задайте срокове на заявките и удостоверяване на прокси отделно според нуждите на приложението.

Методът за прокси на конструктора записва избор на ниво клиент. Това прави политиката по-лесна за проверка от последователност от глобални записи, обвити около асинхронни операции.

Глобалните настройки все още имат приложение

Една политика за прокси в целия JVM може да е подходяща, когато всеки участващ клиент трябва да я следва. Задайте тази политика при стартиране на приложението и проверете кои библиотеки я спазват.

Проблеми възникват, когато глобалните свойства се използват като временен превключвател за отделни заявки. В сървър фоновите работници и библиотечните извиквания могат да работят едновременно, дори вашият метод да изглежда синхронен. Пазете състоянието на маршрутизиране при клиента или конектора, който притежава връзката, така че друга заявка да не може да го промени по средата на работата.