Client.Transport न बदलता Go HTTP प्रॉक्सी मार्ग बदलें
सक्रिय http.Client फील्ड न बदलता नवीन कॉन्फिगर केलेला प्रॉक्सी ट्रान्सपोर्ट प्रकाशित करण्यासाठी सिंक्रोनाइझ्ड RoundTripper रॅपर वापरा.
जर http.Client आधीच समवर्ती विनंत्यांद्वारे सामायिक असेल, तर त्याचे Transport फील्ड स्थिर ठेवा. रॅपर सिंक्रोनाइझ करू शकतो की प्रत्येक पुढील फेरीला कोणता पूर्णपणे कॉन्फिगर केलेला ट्रान्सपोर्ट मिळेल:
type routeSlot struct {
mu sync.RWMutex
current http.RoundTripper
}
func (s *routeSlot) RoundTrip(r *http.Request) (*http.Response, error) {
s.mu.RLock()
current := s.current
s.mu.RUnlock()
return current.RoundTrip(r)
}
func (s *routeSlot) Set(next http.RoundTripper) {
s.mu.Lock()
s.current = next
s.mu.Unlock()
}net/http आणि sync वापरून क्लायंट प्रकाशित करण्यापूर्वी तो सुरू करा:
slot := &routeSlot{current: initialTransport}
client := &http.Client{Transport: slot}
slot.Set(nextTransport)initialTransport आणि nextTransport non-nil, पूर्णपणे कॉन्फिगर केलेले आणि समवर्तीतेसाठी सुरक्षित असले पाहिजेत. प्रत्येक प्रॉक्सी ट्रान्सपोर्ट प्रकाशित करण्यापूर्वी तयार करा आणि विनंत्या तो वापरत असताना त्याचे कॉन्फिगरेशन बदलू नका.
लॉक फक्त पॉइंटर स्नॅपशॉटचे संरक्षण करते, त्यामुळे संथ विनंती संपूर्ण नेटवर्क देवाणघेवाणीत राउटिंग लॉक धरून ठेवत नाही. आधीचा स्नॅपशॉट वापरणारी विनंती त्याच ट्रान्सपोर्टवर पुढे जाते; स्विच ती पुन्हा चालवत नाही किंवा तिचे कनेक्शन हलवत नाही.
जुने ट्रान्सपोर्ट अॅप्लिकेशनच्या मर्यादित जीवनचक्रातून ठेवा आणि निवृत्त करा, सुरू असलेले काम पूर्ण होऊ द्या आणि योग्य तेव्हा निष्क्रिय पूल बंद करा. रीडायरेक्ट स्विचनंतर अजून एक RoundTrip घडवू शकतो. जर संपूर्ण वर्कफ्लोला एक मार्ग हवा असेल, तर हा सामायिक सिलेक्टर मध्ये बदलण्याऐवजी वर्कफ्लोच्या सीमेवर तो मार्ग नेमून द्या.