कैसे: वेब सेवा में वेब सेवा और क्लाइंट टाइमआउट प्रबंधित करना?

Question

मैं लॉग इन करने का प्रयास कर रहा हूं कि क्लाइंट को वेब सेवा कॉल पर समय निकालने पर क्या हो रहा है।

नीचे दिए गए हैलोवर्ल्ड कोड पर एक नज़र डालें। यही वह है जो मैं करना चाहता हूं, लेकिन ऐसा लगता है कि IsClientConnected काम नहीं करता है क्योंकि यह हमेशा सच हो जाता है।

[WebMethod] 
public string HelloWorld() { 
    //.. Do the Webservice stuff 
    if (!Context.Response.IsClientConnected) { 
     //Log some vital info about this call that timed out... 
    } 
    return "The WebService Result"; 
} 

क्या किसी को वेब सेवा कॉल की स्थिति की जांच करने का कोई और तरीका पता है?

जब ग्राहक किसी webservice कॉल से डिस्कनेक्ट होते हैं, तो वेब सेवा में कोई अपवाद नहीं फेंक दिया जाता है। कोड तब तक चलने के लिए जारी रहता है जब तक यह नहीं किया जाता है और फिर इसके परिणाम को शून्यता में लौटाता है (क्योंकि कनेक्शन बंद है)।

Answer 1

मैं उम्मीद करता हूं कि प्रत्येक वेब सेवा कॉल अनुरोध/प्रतिक्रिया होगी। एक त्रुटि की स्थिति में जैसे सेवा अनुपलब्ध या टाइमआउट्स है, मुझे उम्मीद है कि अपवाद को फेंक दिया जाएगा।

तो क्या कॉल को पकड़ने के साथ कॉल करना संभव है?

Answer 2

कुछ ध्वज की जांच करने के बजाय किसी भी प्रकार की घटना की सदस्यता लेना बेहतर है। असल में, एएसपी.नेट अनुरोध को मार रहा है क्योंकि यह कॉन्फ़िगर किए गए टाइमआउट मान (httpRuntime तत्व में निष्पादनटाइम सेटिंग) से अधिक समय ले रहा है। हालांकि, मुझे यकीन नहीं है कि एएसपी.नेट रनटाइम से ऐसी कोई घटना है या नहीं। जाहिर है, यह किसी भी अपवाद को बढ़ाता नहीं है। तो इस विशेष मामले में आपकी सेवा और एएसपी.नेट रनटाइम के बीच एक डिस्कनेक्ट प्रतीत होता है। मुझे यह जानने में दिलचस्पी होगी कि क्या आपके पास बाद में पूरा करने का कोई तरीका/चाल है।

इस बीच, आप एएसपी.NET प्रदर्शन काउंटर में देख सकते हैं। 'अनुरोध समय समाप्त' कहा जाता है। इसमें कतार में या निष्पादन के दौरान प्रतीक्षा किए जाने वाले अनुरोध शामिल हो सकते हैं। आप शुरुआत में और अपनी वेब विधि के अंत में अपनी वेब सेवा के लिए उस प्रदर्शन काउंटर को पढ़ सकते हैं। यदि संख्या कूद गई है, तो इसका मतलब है कि सिर्फ एक समय का अनुरोध। यह जरूरी नहीं हो सकता कि कूद उस विशेष अनुरोध से मेल खाता है लेकिन किसी भी मामले में आप अभी भी कुछ जानकारी लॉग कर सकते हैं जैसे कि वेब विधि, बीत चुके समय आदि को पारित पैरामीटर, जो सहायक हो सकते हैं। यदि आप ग्राहकों को तत्काल समाधान की आवश्यकता है तो आप तेजी से चलाने के लिए अपनी वेब विधि को अनुकूलित करने का प्रयास कर रहे समय के लिए web.config में निष्पादनटाइमआउट मान को भी बढ़ा सकते हैं।

यदि यह एक एएसएमएक्स वेब सेवा है, तो आप global.asax में सत्र_इंड ईवेंट को देखना चाह सकते हैं। एएसपी.नेट ने अनुरोध को मारने पर इसे बुलाया जा सकता है।

बस कुछ विचार।

Answer 3

यह आपके द्वारा उपयोग किए जा रहे वेब सेवा ढांचे के विवरण पर निर्भर करेगा। जो भी आप दिखाते हैं उससे मैं असुरक्षित होगा यदि आपको इसका पता लगाने के लिए कोई तंत्र नहीं है।

ध्यान दें कि सामान्य रूप से एक वेब सेवा को HTTP जैसे परिवहन का उपयोग करने की आवश्यकता नहीं होती है, तो आप कतारों या यहां तक ​​कि ईमेल के माध्यम से प्रतिक्रिया दे सकते हैं। आम तौर पर आप एक साधारण वेब सेवा के सर्वर कार्यान्वयन के रूप में नहीं कर सकते हैं, यह सुनिश्चित कर लें कि आपके ग्राहक ने जवाब देखा है। यदि आपका परीक्षण काम करता है तो आप क्या अनुमान लगाएंगे? तत्काल आप परीक्षण कर चुके हैं, वह लॉग इन न करने का फैसला करने के बाद एक नैनो-सेकंड है, लेकिन वापस लौटने से पहले वह चला गया है। सरल SOAP/HTTP में क्लाइंट और सर्वर के बीच कोई लेनदेन संबंध नहीं है।

इन मुद्दों में से कुछ को हल करने के लिए अतिरिक्त वेब सेवा मानकों हैं, लेकिन आम तौर पर आप अपनी वेब सेवाओं को इस धारणा पर डिजाइन करने के लिए तैयार हैं कि कॉलर उत्तर नहीं देख सकता है। (शायद आप स्टेटस सेवाएं भी प्रदान करते हैं, इसलिए एक ग्राहक बंद हो सकता है और फिर वापस आकर पूछ सकता है "क्या आपने आदेश संसाधित किया" 345 ")।

कृपया हमें बताएं कि आप इस लॉगिंग के साथ क्या हासिल करना चाहते हैं, शायद किसी के पास मदद करने के लिए एक डिज़ाइन दृष्टिकोण है।

Answer 4

HTTP प्रोटोकॉल में कोई विनिर्देश नहीं है कि सर्वर क्लाइंट को कैसे पिंग कर सकता है। IsClientConnected की भावना - यह जांचने के लिए कि क्या HttpResponse प्रस्तुत करने के लिए कुछ 'असंतुष्ट' क्वेरी मौजूद है या नहीं। और हो सकता है (मुझे यकीन नहीं है) यदि ग्राहक रख-रखाव-जिंदा समर्थन करता है।

आर्किटेक्चर खींचने के बारे में सोचें - क्या आपके पास एक तरफा तरीका है, और क्लाइंट साइड से कुछ घड़ी-कुत्ते विधिबद्ध तरीके से जांचने के लिए समय-समय पर जांचते हैं।

Answer 5

मुझे लगता है कि IsClient को झूठी वापसी के लिए कनेक्ट करने के लिए, आपके वेब सेवा कोड का हिस्सा "// .. वेबसाइट सेवा सामग्री" को क्लाइंट की टाइमआउट सेटिंग से निष्पादित करने में अधिक समय लेना होगा। आप क्लाइंट के टाइमआउट को 60 सेकंड तक सेट करके और थ्रेड (70000) को अपने वेब सेवा कोड में IsClientConnected कॉल से पहले सेट करके अनुकरण कर सकते हैं।

हालांकि, मुझे नहीं लगता कि इसके परिणामस्वरूप IsClientConnected की वापसी झूठी होगी। वेब सेवा अनुरोध पर समय समाप्त करना और सर्वर से कनेक्शन रीसेट करना दो अलग-अलग जानवर हैं। अगर प्रतिक्रिया में IsClientStillWaitingForThisWebServiceCallToReturn नामक एक विधि थी, जो आप चाहते हैं वह कर सकता है।

मुझे लगता है कि यदि आप IsClientConnected चेक से पहले वेब सेवा विधि अभी भी भाग में थे, लेकिन मुझे लगता है कि यह वही नहीं है जो आप चाहते हैं तो क्लाइंट को क्लाइंट से नेटवर्क से डिस्कनेक्ट कर दिया गया है, लेकिन मुझे लगता है कि यह वही नहीं है जो आप चाहते हैं।

Answer 6

मुझे विश्वास नहीं है कि सामान्य रूप से अपवाद होगा। यहां तक ​​कि यदि सेवा एक लंबी प्रतिक्रिया वापस भेज रही थी, जैसे कि आउटगोइंग ट्रांसमिशन विंडो बंद हो गई थी, और बाइट भेजने में सक्षम होने का इंतजार कर रहा था, यह सब वेब विधि एएसपी.NET पर वापस लौटने के बाद घटित होगा।

आपको क्या करना चाहिए यह जानना है कि कौन सी वेब विधियां बहुत अधिक समय ले रही हैं। आप "Enabling Tracing in ASP.NET Web Services" में दिखाए गए अनुसार ट्रेसिंग चालू करके ऐसा करना शुरू कर सकते हैं। इसके बाद आपको आगे जाने की आवश्यकता हो सकती है, और यह देखने के लिए सेवा प्रोफाइल करनी चाहिए कि समय कहां खर्च किया जा रहा है।

आपको ईवेंट लॉग पर ध्यान से देखना चाहिए। विशेष रूप से, "एएसपी.नेट" घटना स्रोत से चेतावनी घटनाओं की तलाश करें। ये ASP.NET Health Monitoring से आते हैं। मैं आपको स्वास्थ्य निगरानी प्रणाली को जानने की सलाह देता हूं, क्योंकि आपको लगता है कि यह आपके लिए कई चीजें करता है कि आपको कॉन्फ़िगरेशन की लागत पर खुद को लिखना होगा।

Answer 7

मैं एक साधारण परीक्षण ग्राहक बनाया है और एक सोप WebService कॉल अंदर 100ms

 HttpWebRequest MakeRequest = (HttpWebRequest)WebRequest.Create("http://localhost:55959/ScanServer.asmx"); 
     if (MakeRequest == null) 
     { 
      throw new Exception(); 
     } 
     HttpWebResponse PostResponse = null; 

     MakeRequest.Method = "POST"; 
     MakeRequest.AuthenticationLevel = System.Net.Security.AuthenticationLevel.None; 
     MakeRequest.UserAgent = "testing"; 
     MakeRequest.Timeout = 100; 
     MakeRequest.ContentType = "application/soap+xml; charset=utf-8;"; 

     try 
     { 
      byte[] PostBytes = UTF8Encoding.UTF8.GetBytes(PostData); 
      MakeRequest.ContentLength = PostBytes.Length; 

      Stream RequestStream = MakeRequest.GetRequestStream(); 
      RequestStream.Write(PostBytes, 0, PostBytes.Length); 

      PostResponse = (HttpWebResponse)MakeRequest.GetResponse(); 
     } 
     catch 
     { 
      throw; 
     } 

में समयबाह्य करने की जबकि डिबगिंग मैं एक ब्रेक मुद्दे पर इंतजार कर रहे थे जब तक ग्राहक टाइमआउट अपवाद प्राप्त मेरे अनुरोध निर्धारित किया है। फिर Context.Response.IsClientConnected का मान गलत पर सेट किया गया था। मैंने फिडलर का अनुरोध भी भेजने के लिए किया था और जब सर्वर ब्रेक पॉइंट पर मैंने सत्र रद्द कर दिया था। फिर मूल्य गलत पर सेट किया गया था।

मुझे नुकसान होता है कि आप टाइम क्लाइंट को जांचने के दौरान डेटा लॉग इन करने में सक्षम होने के बिना टाइमआउट क्यों देख रहे हैं, जब तक कि आपके सर्वर के प्रारंभिक कनेक्शन में टाइमआउट न हो।