એક થ્રેડ પ્રોક્સી પ્રોપર્ટી સેટ કરે છે, વિનંતી કરે છે અને જૂની કિંમત પુનઃસ્થાપિત કરે છે. બીજો થ્રેડ બીજી પ્રોક્સી સાથે એ જ કરે છે. ઉપરથી નીચે વાંચતી વખતે કોડ સુઘડ લાગે છે, પરંતુ બંને થ્રેડ 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 પ્રોક્સી સૂચિ ઉમેદવાર એન્ડપોઇન્ટ પૂરા પાડે છે. એપ્લિકેશનની જરૂરિયાતો અનુસાર વિનંતી સમયમર્યાદા અને પ્રોક્સી પ્રમાણીકરણ અલગથી ગોઠવો.

બિલ્ડરની પ્રોક્સી પદ્ધતિ ક્લાયન્ટ-સ્તરની પસંદગી નોંધે છે. તે નીતિને એસિંક્રોનસ ક્રિયાઓની આસપાસ લપેટાયેલા વૈશ્વિક લેખનની ક્રમ કરતાં નિરીક્ષણ કરવા માટે સરળ બનાવે છે.

વૈશ્વિક સેટિંગ્સનો હજી ઉપયોગ છે

જ્યારે દરેક ભાગ લેતા ક્લાયન્ટે તેનું પાલન કરવાનું હોય ત્યારે સમગ્ર JVM માટે એક જ પ્રોક્સી નીતિ યોગ્ય હોઈ શકે છે. એપ્લિકેશન શરૂ થાય ત્યારે તે નીતિ સેટ કરો અને કઈ લાઇબ્રેરીઓ તેનું સન્માન કરે છે તે ચકાસો.

સમસ્યાઓ ત્યારે ઊભી થાય છે જ્યારે વૈશ્વિક પ્રોપર્ટીઓનો ઉપયોગ વ્યક્તિગત વિનંતીઓ માટે કામચલાઉ સ્વિચ તરીકે થાય છે. સર્વરમાં, બેકગ્રાઉન્ડ વર્કર્સ અને લાઇબ્રેરી કૉલ્સ સમાંતર રીતે ચાલી શકે છે, પછી ભલે તમારી પોતાની પદ્ધતિ સિંક્રોનસ લાગે. રૂટિંગ સ્થિતિને તે ક્લાયન્ટ અથવા કનેક્ટર પાસે રાખો જે કનેક્શનનો માલિક છે, જેથી બીજી વિનંતી કામની વચ્ચે તેને બદલી ન શકે.

સંબંધિત લેખો