Една нишка поставува својство за прокси, прави барање и ја враќа старата вредност. Друга нишка го прави истото со друг прокси. Кодот изгледа уредно кога се чита од горе надолу, но двете нишки ја менуваат споделената 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 може да биде соодветна кога секој вклучен клиент треба да ја следи. Поставете ја таа политика при стартување на апликацијата и проверете кои библиотеки ја почитуваат.

Проблеми настануваат кога глобалните својства се користат како привремен прекинувач за поединечни барања. Во сервер, позадинските работници и повикувањата на библиотеки можат да работат паралелно дури и ако вашиот метод изгледа синхрон. Чувајте ја состојбата за рутирање во клиентот или конекторот што ја поседува врската, за да не може друго барање да ја смени на средина од работата.

Поврзани статии