درخواست‌های هم‌زمان Java می‌توانند تنظیمات پروکسی اشتباه را به اشتراک بگذارند

یک نخ یک ویژگی پروکسی را تنظیم می‌کند، درخواستی می‌فرستد و مقدار قبلی را بازمی‌گرداند. نخ دیگری همین کار را با پروکسی متفاوتی انجام می‌دهد. کد هنگام خواندن از بالا به پایین مرتب به نظر می‌رسد، اما هر دو نخ وضعیت مشترک JVM را تغییر می‌دهند.

System.setProperty() یک ویژگی سیستمی را برای فرایند تغییر می‌دهد. این کار مسیری به نخی که آن را فراخوانی کرده متصل نمی‌کند. یک درخواست هم‌زمان می‌تواند مقداری را ببیند که برای کار شخص دیگری نوشته شده است، و ممکن است یک کلاینت موجود قبلاً پیکربندی خودش را گرفته باشد.

مسیر را بخشی از کلاینت کنید

برای کلاینت HTTP جاوا، کلاینت‌ها را با انتخابگرهای پروکسی آگاهانه بسازید. وقتی بارهای کاری به سیاست‌های مسیریابی متفاوت نیاز دارند، کلاینت‌های جداگانه نگه دارید:

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

importها java.net، java.net.http و java.time هستند. آدرس نمونه است؛ برای آزمون‌های مجاز مسیرهای عمومی، فهرست پروکسی HTTP نقاط پایانی نامزد را فراهم می‌کند. مهلت‌های درخواست و احراز هویت پروکسی را جداگانه بر اساس نیازهای برنامه پیکربندی کنید.

متد proxy سازنده یک انتخاب در سطح کلاینت ثبت می‌کند. این کار بازرسی سیاست را آسان‌تر از دنباله‌ای از نوشتن‌های سراسری می‌کند که دور عملیات ناهم‌زمان پیچیده شده‌اند.

تنظیمات سراسری هنوز کاربرد دارند

یک سیاست پروکسی واحد در کل JVM می‌تواند مناسب باشد وقتی همه کلاینت‌های مشارکت‌کننده باید از آن پیروی کنند. آن سیاست را هنگام راه‌اندازی برنامه تنظیم کنید و بررسی کنید کدام کتابخانه‌ها آن را رعایت می‌کنند.

مشکلات زمانی پیش می‌آیند که ویژگی‌های سراسری به‌عنوان کلید موقت برای درخواست‌های فردی استفاده شوند. در یک سرور، کارگران پس‌زمینه و فراخوانی‌های کتابخانه می‌توانند هم‌زمان اجرا شوند حتی اگر متد خود شما هم‌زمان به نظر برسد. وضعیت مسیریابی را نزد کلاینت یا اتصال‌دهنده‌ای نگه دارید که مالک اتصال است، تا درخواست دیگری نتواند آن را در میانه کار تغییر دهد.