Адзін паток задае ўласцівасць проксі, робіць запыт і аднаўляе старое значэнне. Іншы паток робіць тое ж з іншым проксі. Код выглядае ахайна пры чытанні зверху ўніз, але абодва паткі змяняюць агульны стан 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 можа быць мэтазгоднай, калі кожны кліент-удзельнік павінен ёй ісці. Задайце гэтую палітыку пры запуску праграмы і праверце, якія бібліятэкі яе выконваюць.

Праблемы ўзнікаюць, калі глабальныя ўласцівасці выкарыстоўваюцца як часовы перамыкач для асобных запытаў. У серверы фонавыя працоўныя і выклікі бібліятэк могуць выконвацца адначасова, нават калі ваш метад выглядае сінхронным. Трымайце стан маршрутызацыі пры кліенце або злучальніку, які валодае злучэннем, каб іншы запыт не мог змяніць яго пасярэдзіне працы.

Падобныя артыкулы