एकाच वेळी चालणाऱ्या Java विनंत्या चुकीच्या प्रॉक्सी सेटिंग्ज सामायिक करू शकतात

एक थ्रेड प्रॉक्सी प्रॉपर्टी सेट करतो, विनंती करतो आणि जुने मूल्य पुनर्संचयित करतो. दुसरा थ्रेड वेगळ्या प्रॉक्सीसह तेच करतो. वरून खाली वाचल्यास कोड नीटनेटका दिसतो, पण दोन्ही थ्रेड सामायिक JVM स्थिती बदलत आहेत.

System.setProperty() प्रक्रियेची सिस्टम प्रॉपर्टी बदलते. ते कॉल करणाऱ्या थ्रेडला मार्ग जोडत नाही. एकाच वेळी चालणारी विनंती दुसऱ्याच्या कामासाठी लिहिलेले मूल्य पाहू शकते, आणि विद्यमान क्लायंटने आपली स्वतःची कॉन्फिगरेशन आधीच पकडलेली असू शकते.

मार्गाला क्लायंटचा भाग बनवा

Java च्या HTTP क्लायंटसाठी, हेतुपूर्वक निवडलेल्या प्रॉक्सी निवडकांसह क्लायंट तयार करा. कामांना वेगळी राउटिंग धोरणे आवश्यक असल्यास वेगळे क्लायंट ठेवा:

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 साठी एकच प्रॉक्सी धोरण योग्य असू शकते. ते धोरण अनुप्रयोग सुरू होताना सेट करा आणि कोणती लायब्ररी त्याचा आदर करतात ते तपासा.

ग्लोबल प्रॉपर्टीज वैयक्तिक विनंत्यांसाठी तात्पुरता स्विच म्हणून वापरल्या की अडचणी उद्भवतात. सर्व्हरमध्ये, तुमची पद्धत सिंक्रोनस दिसत असली तरी पार्श्वभूमी कामगार आणि लायब्ररी कॉल एकाच वेळी चालू शकतात. राउटिंग स्थिती ज्या क्लायंट किंवा कनेक्टरकडे कनेक्शन आहे त्याच्याकडे ठेवा, जेणेकरून दुसरी विनंती कामाच्या मध्यात ती बदलू शकणार नाही.