בקשות 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 כולו יכולה להתאים כשכל הלקוחות המשתתפים אמורים לפעול לפיה. הגדירו אותה בעת הפעלת היישום ואמתו אילו ספריות מכבדות אותה.

בעיות מתעוררות כשמשתמשים במאפיינים גלובליים כמתג זמני לבקשות בודדות. בשרת, עובדי רקע וקריאות ספרייה יכולים לרוץ במקביל גם אם השיטה שלכם נראית סינכרונית. החזיקו את מצב הניתוב אצל הלקוח או המחבר שבבעלותו החיבור, כדי שבקשה אחרת לא תוכל לשנות אותו באמצע העבודה.