WCF टाइमआउट अपवाद विस्तृत जांच

Question

हमारे पास एक आवेदन है जिसमें IIS7 पर WCF सेवा (* .svc) चल रही है और विभिन्न ग्राहक सेवा को क्वेरी कर रहे हैं। सर्वर Win 2008 सर्वर चला रहा है। क्लाइंट या तो विंडोज 2008 सर्वर या विंडोज 2003 सर्वर चला रहे हैं। मुझे निम्नलिखित अपवाद मिल रहे हैं, जो मैंने देखा है कि वास्तव में बड़ी संख्या में संभावित डब्ल्यूसीएफ मुद्दों से संबंधित हो सकता है।

System.TimeoutException: The request channel timed out while waiting for a reply after 00:00:59.9320000. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. ---> System.TimeoutException: The HTTP request to 'http://www.domain.com/WebServices/myservice.svc/gzip' has exceeded the allotted timeout of 00:01:00. The time allotted to this operation may have been a portion of a longer timeout. 

मैंने समय सीमा बढ़ाकर 30 मिनट कर दी है और त्रुटि अभी भी हुई है। यह मुझे बताता है कि कुछ और खेल में है, क्योंकि डेटा की मात्रा कभी भी अपलोड या डाउनलोड करने के लिए 30 मिनट नहीं ले सकती है।

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

 at System.Net.HttpWebRequest.GetResponse()
  at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)

सर्वर पर: मैंने कोशिश की है (और वर्तमान में) निम्नलिखित बाध्यकारी सेटिंग्स हैं:

maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferPoolSize="2147483647"

इसका असर नहीं दिख रहा है।

मैंने कोशिश की है (और वर्तमान में) निम्न थ्रॉटलिंग सेटिंग्स:

<serviceThrottling maxConcurrentCalls="1500"   maxConcurrentInstances="1500"    maxConcurrentSessions="1500"/>

इसका असर नहीं दिख रहा है।

वर्तमान में मेरे पास WCF सेवा के लिए निम्नलिखित सेटिंग्स हैं।

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Single)]

मैं ConcurrencyMode.Multipleथोड़ी देर तक साथ रहा , और फिर भी त्रुटि हुई।

मैंने IIS को पुनरारंभ करने का प्रयास किया है, मेरे अंतर्निहित SQL सर्वर को पुनरारंभ करके, मशीन को पुनरारंभ करना। इन सबका असर नहीं दिख रहा है।

मैंने Windows फ़ायरवॉल को अक्षम करने का प्रयास किया है। इसका असर नहीं दिख रहा है।

क्लाइंट पर, मेरे पास ये सेटिंग्स हैं:

maxReceivedMessageSize="2147483647"

<system.net>
    <connectionManagement>
    <add address="*" maxconnection="16"/>
</connectionManagement> 
</system.net>

मेरा ग्राहक अपने कनेक्शन बंद कर देता है:

var client = new MyClient();

try
{
    return client.GetConfigurationOptions();
}
finally
{
    client.Close();
}

मैंने अधिक आउटगोइंग कनेक्शन की अनुमति देने के लिए रजिस्ट्री सेटिंग्स बदल दी हैं:

MaxConnectionsPerServer=24, MaxConnectionsPer1_0Server=32.

मैंने अभी हाल ही में SvcTraceViewer.exe की कोशिश की है। मैं ग्राहक अंत पर एक अपवाद को पकड़ने में कामयाब रहा। मैं देखता हूं कि इसकी अवधि 1 मिनट है। सर्वर साइड ट्रेस को देखते हुए, मैं देख सकता हूं कि सर्वर को इस अपवाद के बारे में पता नहीं है। मैं देख सकता हूं कि अधिकतम अवधि 10 सेकंड है।

मैंने exec sp_whoसर्वर पर सक्रिय डेटाबेस कनेक्शन को देखा है। मेरे पास केवल कुछ (2-3) हैं। मैंने TCPview का उपयोग करते हुए एक क्लाइंट से TCP कनेक्शन देखा है। यह आमतौर पर 2-3 के आसपास होता है और मैंने 5 या 6 तक देखा है।

सीधे शब्दों में कहूं तो मैं स्टम्प्ड हूं। मैंने वह सब कुछ करने की कोशिश की है जो मुझे मिल सकता है, और बहुत सरल कुछ याद आ रहा है जिसे डब्ल्यूसीएफ विशेषज्ञ देख पाएंगे। यह मेरे पेट की भावना है कि कुछ मेरे ग्राहकों को निम्न-स्तर (टीसीपी) पर रोक रहा है, इससे पहले कि सर्वर वास्तव में संदेश प्राप्त करता है और / या कुछ सर्वर के स्तर पर संदेशों को कतारबद्ध कर रहा है और उन्हें कभी भी प्रक्रिया नहीं करने देता है।

यदि आपके पास कोई प्रदर्शन काउंटर है जिसे मुझे देखना चाहिए, तो कृपया मुझे बताएं। (कृपया बताएं कि क्या मूल्य खराब हैं, क्योंकि इनमें से कुछ काउंटरों को डिक्रिप्ट करना मुश्किल है)। इसके अलावा, मैं WCF संदेश आकार कैसे लॉग कर सकता हूं? अंत में, क्या हमारे कोई उपकरण हैं जो मुझे यह परखने की अनुमति देंगे कि मैं अपने क्लाइंट और सर्वर के बीच कितने कनेक्शन स्थापित कर सकता हूं (स्वतंत्र रूप से मेरे आवेदन से)

आपके समय के लिए धन्यवाद!

अतिरिक्त जानकारी 20 जून को जोड़ी गई:

मेरा WCF एप्लिकेशन निम्नलिखित के समान कुछ करता है।

while (true)
{
   Step1GetConfigurationSettingsFromServerViaWCF(); // can change between calls
   Step2GetWorkUnitFromServerViaWCF();
   DoWorkLocally(); // takes 5-15minutes. 
   Step3SendBackResultsToServerViaWCF();
}

वायरशर्क का उपयोग करते हुए, मैंने देखा कि जब त्रुटि होती है, तो मेरे पास बाद में एक टीसीपी रीसेट के बाद एक पांच टीसीपी प्रतिक्रांति होती है। मेरा अनुमान है कि RST WCF से कनेक्शन को मार रहा है। मुझे जो अपवाद रिपोर्ट मिलती है वह स्टेप 3 टाइमिंग आउट की है।

मैंने इसे tcp स्ट्रीम "tcp.stream eq 192" को देखकर खोजा। मैंने तब अपने फ़िल्टर को "tcp.stream eq 192 और http.request.method eq POST" में विस्तारित किया और इस स्ट्रीम के दौरान 6 POST देखे। यह अजीब लग रहा था, इसलिए मैंने एक और स्ट्रीम जैसे tcp.stream eq 100 के साथ जांच की। मेरे पास तीन POST थे, जो थोड़ा अधिक सामान्य लगता है क्योंकि मैं तीन कॉल कर रहा हूं। हालाँकि, मैं हर WCF कॉल के बाद अपना कनेक्शन बंद कर देता हूं, इसलिए मुझे प्रति स्ट्रीम एक कॉल की उम्मीद होती (लेकिन मुझे टीसीपी के बारे में ज्यादा जानकारी नहीं है)।

थोड़ी और जांच करते हुए, मैंने इन छह कॉलों को देखने के लिए http पैकेट लोड को डिस्क में डंप कर दिया।

1) Step3
2) Step1
3) Step2
4) Step3 - corrupted
5) Step1
6) Step2

मेरा अनुमान है कि दो समवर्ती ग्राहक एक ही कनेक्शन का उपयोग कर रहे हैं, यही कारण है कि मैंने डुप्लिकेट देखा। हालाँकि, मेरे पास अभी भी कुछ और मुद्दे हैं जिन्हें मैं समझ नहीं सकता:

क) पैकेट क्यों दूषित है? यादृच्छिक नेटवर्क अस्थायी - शायद? इस सैंपल कोड का उपयोग करके लोड को रोक दिया गया है: http://msdn.microsoft.com/en-us/library/ms751458.aspx - क्या समवर्ती रूप से उपयोग किए जाने पर कोड एक बार में छोटी हो सकता है? मुझे gzip लाइब्रेरी के बिना परीक्षण करना चाहिए।

ख) मैं दूषित संचालन के समय के बाद चरण 1 और चरण 2 क्यों देखूंगा? मुझे ऐसा लगता है जैसे ये ऑपरेशन नहीं होने चाहिए थे। हो सकता है कि मैं सही स्ट्रीम नहीं देख रहा हूं क्योंकि टीसीपी की मेरी समझ त्रुटिपूर्ण है। मेरे पास अन्य धाराएं हैं जो एक ही समय में होती हैं। मुझे अन्य धाराओं की जांच करनी चाहिए - 190-194 की धाराओं पर एक त्वरित नज़र बताती है कि Step3 POST में उचित पेलोड डेटा है (भ्रष्ट नहीं है)। मुझे फिर से गज़िप लाइब्रेरी देखने के लिए धक्का दे दिया।

Comments

जेसन - क्या तुमने कभी इस समस्या को हल किया? क्या यह DefaultConnectionLimit सेटिंग थी?

— SFun28

@JasonKealey - कई अन्य प्रश्नों के विपरीत, आपको प्रश्न पोस्ट करने से पहले खुद के लिए प्रयास नहीं करने का आरोप नहीं लगाया जा सकता है :) मुझे प्यार है कि आपका प्रश्न इतना विस्तृत है, और इसमें सभी महत्वपूर्ण विवरण शामिल हैं। आपके द्वारा वर्णित लक्षण बहुत हद तक मेरे जैसे

— लगते हैं

Answer 1

यदि आप .Net क्लाइंट का उपयोग कर रहे हैं तो आपके पास सेट नहीं हो सकता है

//This says how many outgoing connection you can make to a single endpoint. Default Value is 2
System.Net.ServicePointManager.DefaultConnectionLimit = 200;

यहाँ मूल प्रश्न और उत्तर WCF सेवा थ्रॉटलिंग है

अपडेट :

यह कॉन्‍फ़‍िगर करता है। नेट क्‍लाइंट ऐप्‍लीकेशन आपके परीक्षण शुरू करने से पहले या जब भी शुरू हो सकता है।

इसके अलावा आप इसे app.config फ़ाइल में निम्न की तरह कर सकते हैं

<system.net>
    <connectionManagement>
      <add maxconnection = "200" address ="*" />
    </connectionManagement>
  </system.net>

Comments

यह आशाजनक लग रहा है। मैंने इसे अपने अगले स्केलेबिलिटी टेस्ट के दौरान जांचने के लिए शामिल किया है। यह बिल्कुल उस तरह की यादृच्छिक सेटिंग की तरह दिखता है जो इसे दुर्घटनाग्रस्त कर देगा :) सूचक के लिए धन्यवाद।

— जेसन केली

@ जेसन: यदि आप सर्वर प्रोग्रामर हैं, तो आप जानते हैं कि आपके हाथों में सर्वर के स्केलेबिलिटी को बनाए रखना कितना महत्वपूर्ण है और साथ ही वह जो वर्तमान में उपर्युक्त समस्या का सामना कर रहा है। कृपया यदि आप निम्नलिखित प्रश्न में देख सकते हैं stackoverflow.com/questions/2637175/wcf-network-cost संक्षेप में मैं क्लाइंट और सर्वर के बीच 31ms विलंबता से पीड़ित हूं और इसे कम करने की आवश्यकता है।

— मुबाशर

इसमें केवल एक साल का समय लगा, लेकिन मैंने आखिरकार इस ध्वज सेट के साथ आवेदन पर एक और तनाव परीक्षण किया। समस्या हल हो गई है, इसलिए मैं आपको सबसे अच्छा जवाब दे रहा हूं। मुझे आश्चर्य नहीं होगा कि यह पहेली का अंतिम टुकड़ा था जो आवश्यक था लेकिन यह सुनिश्चित करने के लिए कि अन्य सभी तत्वों को जगह में रहने की आवश्यकता है जो कि त्रुटि नहीं हुई। बहुत बहुत धन्यवाद!

— जेसन केली

@ ऐरिस: स्टार्टअप पर .net क्लाइंट एप्लीकेटन, या जहां आपने कभी भी अपना ग्लोबल कॉन्फिगरेशन सेट किया है, अगर आप इसे कॉन्फिगरेबल रखना चाहते हैं, तो आप इसे कॉन्फिग फाइल में भी इस तरह जोड़ सकते हैं <system.net> <connectionManagement> <add maxnnection = "200" पता = "*" /> </ कनेक्शन प्रबंधन> </ system.net>

— मुबशेर

Answer 2

यदि आपने इसे पहले ही आज़मा लिया है - अपने सर्वर-साइड WCF ऑपरेशंस को कोशिश / अंत में ब्लॉक में एन्क्रिप्ट करें, और यह सुनिश्चित करने के लिए लॉगिंग जोड़ें कि वे वास्तव में वापस आ रहे हैं।

यदि वे दिखाते हैं कि संचालन पूरा हो रहा है, तो मेरा अगला कदम निचले स्तर पर जाना होगा, और वास्तविक परिवहन परत को देखना होगा।

Wireshark या इसी तरह का एक अन्य पैकेट कैप्चरिंग टूल इस बिंदु पर काफी सहायक हो सकता है। मुझे लगता है कि यह मानक बंदरगाह 80 पर HTTP पर चल रहा है।

ग्राहक पर Wireshark चलाएँ। जब आप कैप्चर शुरू करते हैं तो विकल्पों में, कैप्चर फ़िल्टर को tcp http and host service.example.com - पर सेट करें, इससे अप्रासंगिक ट्रैफ़िक की मात्रा कम हो जाएगी।

यदि आप कर सकते हैं, तो कॉल के सटीक प्रारंभ समय और समय समाप्त होने पर आपको सूचित करने के लिए अपने क्लाइंट को संशोधित करें। या बस बारीकी से इसकी निगरानी करें।

जब आपको कोई त्रुटि मिलती है, तो आप कॉल की शुरुआत का पता लगाने के लिए Wireshark लॉग के माध्यम से पता लगा सकते हैं। पहले पैकेट पर राइट क्लिक करें जिसमें आपके क्लाइंट को कॉल करना है (GET /service.svc या POST /service.svc की तरह कुछ होना चाहिए) और टीसीपी स्ट्रीम का चयन करें।

Wireshark पूरे HTTP वार्तालाप को डिकोड करेगा, इसलिए आप यह सुनिश्चित कर सकते हैं कि WCF वास्तव में प्रतिक्रियाएं भेज रहा है।

Comments

मेरे पास सर्वर पर लॉगिंग है - उस छोर पर कोई त्रुटि नहीं है। मैं अभी वायरशर्क चला रहा हूं, यह देखने के लिए कि मुझे क्या मिल सकता है। यातायात की उच्च मात्रा को देखते हुए, यह विश्लेषण करने के लिए एक दर्द होने जा रहा है लेकिन अगर मुझे कुछ भी मिल सकता है तो मैं वापस रिपोर्ट करूंगा।

— जेसन केली

मैंने पिछले छह घंटों में वायरशर्क को चलाया और कुछ 60k फ्रेम एकत्र किए। इस ग्राहक द्वारा केवल एक अपवाद की सूचना दी गई थी। मैंने RST (रीसेट) के रूप में चिह्नित टीसीपी कनेक्शन को देखा था, जाहिरा तौर पर त्रुटि ईमेल भेजने के बाद, जो संभवतः डब्ल्यूसीएफ है जो कनेक्शन को समाप्त कर रहा है। मैंने डिस्क को पेलोड (525k) बचाया। मैंने सत्यापित किया कि समान आकार के पेलोड के साथ 87 अन्य आह्वान थे। मैंने कुछ टीसीपी रिट्रांसमिशन देखे, लेकिन कुछ अन्य कॉल में भी देखा (जो असफल नहीं हुआ)। मेरे नेटवर्किंग हार्डवेयर + केबलों के बारे में आश्चर्य करना शुरू करना।

— जेसन केली

यहां तक ​​कि एक स्थानीय नेटवर्क पर, एक टीसीपी रिट्रांसमिट्स की उपस्थिति जरूरी नहीं है। यदि अंत में भौतिक रूप से दो बिंदुओं को एक स्विच से जोड़ना संभव है, तो यह एक शॉट के लायक हो सकता है, लेकिन मैं आशा नहीं करूंगा कि यह ठीक हो जाएगा। यदि आप कर सकते हैं - एक बहुत ही बुनियादी क्लाइंट एप्लिकेशन बनाएं जो आपके ट्रैफ़िक को आगे और पीछे कुछ ट्रैफ़िक पास करता है, और कुछ नहीं। यह आपके आवेदन में किसी भी मुद्दे को समाप्त करने में मदद कर सकता है जो समयबाह्य हो सकता है।

इसके अलावा, आप टीसीपी रीसेट पैकेट को देखने का उल्लेख करते हैं - क्या सर्वर ने उस बिंदु पर किसी भी तरह की प्रतिक्रिया दी थी (या शायद यह किसी डेटा की प्रतीक्षा कर रहा था)? क्या आरएसटी और पिछले पैकेट के बीच एक सराहनीय देरी थी?

सर्वर दूरस्थ है। मैं स्थानीय स्तर पर एक परीक्षण वातावरण बनाने की योजना बना रहा हूं ताकि यह देखा जा सके कि क्या मदद करता है। आरएसटी के लिए, यह पांच सेकंड के रिट्रांसमिशन के अंतिम के बाद 34 सेकंड के लिए भेजा गया था। (1 से 8 सेकंड के अंतराल के बीच रिट्रांसमिशन)। क्या इससे आपको कोई सुराग मिलता है?

— जेसन केली

Answer 3

से: http://www.codeproject.com/KB/WCF/WCF_Operation_Timeout_.aspx

इस टाइमआउट त्रुटि से बचने के लिए, हमें WCF क्लाइंट कोड में प्रॉक्सी के लिए OperationTimeout प्रॉपर्टी को कॉन्फ़िगर करना होगा । यह कॉन्फ़िगरेशन अन्य कॉन्फ़िगरेशन जैसे सेंड टाइमआउट, रिसीव टाइमआउट आदि के विपरीत कुछ नया है, जिसकी मैंने लेख में जल्दी चर्चा की थी। इस ऑपरेशन टाइमआउट प्रॉपर्टी कॉन्फ़िगरेशन को सेट करने के लिए, हमें ऑपरेशन कॉन्ट्रैक्ट के तरीकों को कॉल करने से पहले WCF क्लाइंट एप्लिकेशन में IContextChannel पर अपना प्रॉक्सी डालना होगा।

Comments

मैंने यह कोशिश की है। भले ही मैं कितना भी समय लगाऊं, यह अभी भी समय से बाहर है लेकिन इसका कोई मतलब नहीं है क्योंकि ऑपरेशन उतना लंबा नहीं है और क्योंकि सभी अन्य क्लाइंट जो इस समय के दौरान एक ही क्वेरी काम करते हैं।

— जेसन केली

मेरे परीक्षणों ने साबित कर दिया कि ऑपरेशन टाइमआउट केवल कॉन्फिगर टाइमआउट को कॉन्फिगर से ओवरराइड करता है। इस प्रकार, इसका कोई फायदा नहीं है।

— dudeNumber4

Answer 4

मैं एक बहुत ही इसी तरह की समस्या है। अतीत में, यह क्रमिक समस्याओं से संबंधित रहा है। यदि आपको अभी भी यह समस्या हो रही है, तो क्या आप यह सत्यापित कर सकते हैं कि आप उन वस्तुओं को सही ढंग से अनुक्रमित कर सकते हैं जिन्हें आप वापस कर रहे हैं। विशेष रूप से, यदि आप संबंध बनाने वाली Linq-To-Sql ऑब्जेक्ट का उपयोग कर रहे हैं, तो ज्ञात क्रमांकन समस्याएं हैं यदि आप किसी चाइल्ड ऑब्जेक्ट पर पैरेंट ऑब्जेक्ट पर बैक रेफरेंस डालते हैं और उस बैक संदर्भ को एक DataMember के रूप में चिह्नित करते हैं।

आप सांत्वना ऐप लिखकर क्रमबद्धता को सत्यापित कर सकते हैं जो सर्वर साइड पर DataContractSerializer का उपयोग करके अपनी वस्तुओं को क्रमबद्ध और निष्क्रिय करता है और जो भी क्रमांकन आपके ग्राहक द्वारा उपयोग किया जाता है। उदाहरण के लिए, हमारे वर्तमान एप्लिकेशन में, हमारे पास WPF और कॉम्पैक्ट फ्रेमवर्क क्लाइंट दोनों हैं। मैंने यह प्रमाणित करने के लिए एक सांत्वना ऐप लिखा है कि मैं एक DataContractSerializer का उपयोग करके अनुक्रमित कर सकता हूं और XmlDesserializer का उपयोग करके deserialize कर सकता हूं। आप कोशिश कर सकते हैं कि

इसके अलावा, यदि आप Linq-To-Sql ऑब्जेक्ट वापस कर रहे हैं जिसमें बाल संग्रह हैं, तो आप यह सुनिश्चित करने का प्रयास कर सकते हैं कि आपने सर्वर पर उत्सुकता से उन्हें लोड किया है। कभी-कभी, आलसी लोडिंग के कारण, लौटाए जाने वाले ऑब्जेक्ट पॉपुलेट नहीं किए जाते हैं और आपके द्वारा देखे जाने वाले व्यवहार का कारण बन सकता है जहां अनुरोध को सेवा विधि में कई बार भेजा जाता है।

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

अद्यतन: मुझे यकीन नहीं है कि यह आपकी किसी भी मदद करेगा, लेकिन सर्विस ट्रेस व्यूअर टूल ने आपकी समस्या के 5 दिनों के अनुभव के बाद मेरी समस्या को हल कर दिया। ट्रेसिंग सेट करने और फिर कच्चे XML को देखने से, मुझे उन अपवादों का पता चला जो मेरी क्रमिक समस्याओं का कारण बन रहे थे। यह Linq-to-SQL ऑब्जेक्ट्स से संबंधित था जो कभी-कभी अधिक ऑब्जेक्ट्स से बच्चे को सफलतापूर्वक अनुक्रमित किया जा सकता था। निम्नलिखित को अपने web.config फ़ाइल में जोड़ना ट्रेसिंग सक्षम करना चाहिए:

<sharedListeners>
    <add name="sharedListener"
         type="System.Diagnostics.XmlWriterTraceListener"
         initializeData="c:\Temp\servicetrace.svclog" />
  </sharedListeners>
  <sources>
    <source name="System.ServiceModel" switchValue="Verbose, ActivityTracing" >
      <listeners>
        <add name="sharedListener" />
      </listeners>
    </source>
    <source name="System.ServiceModel.MessageLogging" switchValue="Verbose">
      <listeners>
        <add name="sharedListener" />
      </listeners>
    </source>
  </sources>

परिणामी फ़ाइल को सर्विस ट्रेस व्यूअर टूल के साथ या केवल IE में परिणाम की जांच करने के लिए खोला जा सकता है।

Answer 5

क्या आप अनुरोधों के बीच WCF सेवा से कनेक्शन बंद कर रहे हैं? यदि आप नहीं करते हैं, तो आपको यह सटीक समयबाह्य (अंततः) दिखाई देगा।

Answer 6

मैंने अभी समस्या हल की है। मैंने पाया कि App.config फ़ाइल में नोड्स गलत कॉन्फ़िगर किए गए हैं।

<client>
<endpoint name="WCF_QtrwiseSalesService" binding="wsHttpBinding" bindingConfiguration="ws" address="http://cntgbs1131:9005/MyService/TGE.ISupplierClientManager" contract="*">
</endpoint>
</client>

<bindings>
    <wsHttpBinding>
        <binding name="ws" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" messageEncoding="Text">
            <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
            <**security mode="None">**
                <transport clientCredentialType="None"></transport>
            </security>
        </binding>
    </wsHttpBinding>
</bindings>

नोड में अपने कॉन्फ़िगरेशन की पुष्टि करें <security>, विशेषता "मोड" मान "कोई नहीं" है। यदि आपका मान "ट्रांसपोर्ट" है, तो त्रुटि उत्पन्न होती है।

Comments

क्या इससे सुरक्षा प्रभावित नहीं होती है? यदि ऐसा है तो यह अधिकांश वास्तविक अनुप्रयोगों के लिए समाधान नहीं हो सकता है

— विवेके

Answer 7

क्या आपने भेजे गए संदेश को देखने के लिए एसओएपी टूलकिट या ऐसा कुछ उपयोग करके क्लाइंटविआ का उपयोग करने की कोशिश की ? यह देखने में मदद कर सकता है कि क्या त्रुटि क्लाइंट से या कहीं और से आ रही है।

Comments

क्या आप किसी भी उपकरण को हटाए गए SOAP टूलकिट से अधिक हाल ही में जानते हैं जो WCF कॉल में इस जानकारी को लॉग इन करना मेरे लिए आसान बना देगा?

— जेसन केली

SOAP टूलकिट हैdeprecated

— Kiquenet

Answer 8

क्या आपने डब्ल्यूसीएफ निशान की जांच की? WCF में अपवादों को निगलने की प्रवृत्ति होती है और केवल अंतिम अपवाद को लौटाते हैं, जो कि आपको मिल रहा है, क्योंकि अंतिम बिंदु कुछ भी सार्थक नहीं लौटा है।

Comments

मैंने SvcTraceViewer की कोशिश की और एकमात्र अपवाद जो इसकी रिपोर्ट किया गया वह था टाइमआउट (क्लाइंट पर)। सर्वर पर कुछ भी नहीं बताया गया था।

— जेसन केली

ट्रेस पर सभी विकल्प खोलें, हो सकता है कि आपके पास सभी ट्रेस विकल्प खुले न हों। इसके अलावा, इवेंट ट्रेस और संदेश ट्रेस फ़ाइलों दोनों की जाँच करें।

— मिकी वाट्स

Answer 9

यदि आप क्लाइंट के पास कोई ऑब्जेक्ट पास कर रहे हैं तो आपको यह त्रुटि भी मिलेगी, जिसमें टाइप एनम की एक संपत्ति है जो डिफ़ॉल्ट रूप से सेट नहीं है और उस एनम का मान नहीं है जो कि मैप्स 0. है। enum MyEnum{ a=1, b=2};

Answer 10

ऐसा लगता है कि यह अपवाद संदेश काफी सामान्य है और कई कारणों से प्राप्त किया जा सकता है। विंडोज 8.1 मशीनों पर क्लाइंट को तैनात करते समय हम इसमें भाग गए। हमारा WCF क्लाइंट विंडोज सर्विस के अंदर चलता है और लगातार WCF सर्विस को पोल करता है। विंडोज़ सेवा एक गैर-व्यवस्थापक उपयोगकर्ता के अंतर्गत चलती है। निम्नलिखित के रूप में प्रमाणीकरण को पास-थ्रू करने की अनुमति देने के लिए WCF कॉन्फ़िगरेशन में "Windows" के लिए क्लाइंटक्रेडिटिव टाइप सेट करके समस्या को ठीक किया गया था:

      <security mode="None">
        <transport clientCredentialType="Windows" proxyCredentialType="None"
          realm="" />
        <message clientCredentialType="UserName" algorithmSuite="Default" />
      </security>

Answer 11

मैं WCF विशेषज्ञ नहीं हूं, लेकिन अगर आप IIS पर DDOS सुरक्षा में नहीं चल रहे हैं, तो मुझे आश्चर्य हो रहा है। मैं अनुभव से जानता हूं कि यदि आप किसी एकल क्लाइंट से सर्वर पर एक साथ कनेक्शन का एक गुच्छा किसी बिंदु पर चलाते हैं तो सर्वर कॉल का जवाब देना बंद कर देता है क्योंकि यह डीडीओएस हमले पर संदेह करता है। यह तब तक खुला कनेक्शन भी रखेगा जब तक कि वह अपने हमलों में ग्राहक को धीमा करने के लिए टाइम-आउट नहीं करता।

हालांकि, विभिन्न मशीनों / आईपी से आने वाले कई कनेक्शन को कोई समस्या नहीं होनी चाहिए।

इस MSDN पोस्ट में अधिक जानकारी है:

http://msdn.microsoft.com/en-us/library/bb463275.aspx

MaxConcurrentSession sproperty की जाँच करें।

Comments

मुझे लगता है कि यह वही हो रहा है, जो कुछ मैंने देखा है, हालाँकि, मैंने (सर्वर पर): <serviceThrottling maxConcurrentCalls = "150" maxConcurrentInstances = "150" maxConcurrentSessions = "150" /> <serviceDebug शामिल करेंExceptionDetailInFaults = "सत्य" /> क्या कोई प्रदर्शन मॉनीटर या IIS लॉग होगा जो मैं देख सकता था कि क्या यह हो रहा है?

— जेसन केली