2008-11-04 18 views
59

मुझे निम्न त्रुटि मिल रही है जब मेरा win32 (C#) ऐप वेब सेवाओं को कॉल कर रहा है।HTTP स्थिति 504

The request failed with HTTP status 504: Gateway timeout server response timeout. 

मैं समझता हूं कि 'मुझे लगता है' ऐसा इसलिए है क्योंकि अपस्ट्रीम अनुरोध को समय-समय पर प्रतिक्रिया नहीं मिलती है।

लेकिन मेरा सवाल यह है? मैं अपने Win32 एप्लिकेशन में app.config सेटिंग्स को अपने डेटा को संसाधित करने के लिए अधिक समय देने के लिए कैसे बदलूं। मुझे लगता है कि मुझे इन ऐप सेटिंग्स में इन बदलावों की आवश्यकता है क्योंकि वेब सर्विसेज और आईआईएस होस्टिंग डब्ल्यूएस विस्तारित समय के साथ सेटअप हैं।

एक प्रतिक्रिया के लिए तत्पर हैं और अग्रिम धन्यवाद।

स्कॉट

उत्तर

18

CheckUpDown a nice explanation of the 504 error है:

एक सर्वर (जरूरी नहीं एक वेब सर्वर) एक गेटवे या प्रॉक्सी के रूप में काम कर रहा है ग्राहक द्वारा अनुरोध जैसे अपने वेब ब्राउज़र या हमारे CheckUpDown पूरा करने के लिए (रोबोट) अनुरोधित यूआरएल तक पहुंचने के लिए। इस सर्वर को आपके HTTP अनुरोध से निपटने के लिए उपयोग किए गए अपस्ट्रीम सर्वर से समय पर प्रतिक्रिया प्राप्त नहीं हुई थी।

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

यह समस्या पूरी तरह से वेब सर्वर सहित बैक-एंड कंप्यूटरों के बीच धीमी आईपी संचार के कारण है। केवल वे लोग जो साइट पर नेटवर्क सेट अप करते हैं जो वेब सर्वर होस्ट करता है, इस समस्या को ठीक कर सकता है।

41

आप नहीं कर सकते। समस्या यह नहीं है कि आपका ऐप अधीर और समय समाप्त हो गया है; समस्या यह है कि एक मध्यवर्ती प्रॉक्सी अधीर और समय समाप्त हो जाती है। "सर्वर, गेटवे या प्रॉक्सी के रूप में कार्य करते समय, यूआरआई द्वारा निर्दिष्ट अपस्ट्रीम सर्वर से समय पर प्रतिक्रिया प्राप्त नहीं हुई।" (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.5) यह सबसे अधिक संभावना इंगित करता है कि मूल सर्वर में कुछ प्रकार की समस्या है, इसलिए यह अग्रेषित अनुरोध को तुरंत प्रतिसाद नहीं दे रहा है।

संभावित समाधान, जिनमें से कोई भी आप खुश करने के लिए की संभावना है: प्रॉक्सी के

  • बढ़ाएँ टाइमआउट मान (यदि यह आपके नियंत्रण में है)
  • (यदि वहाँ एक और है एक अलग सर्वर के लिए अपने अनुरोध करें एक ही डेटा के साथ सर्वर)
  • आपके अनुरोध को अलग ढंग से करें (यदि संभव हो) ऐसी है कि आप एक समय में कम डेटा का अनुरोध कर रहे
  • एक बार सर्वर समस्याओं
होने नहीं कर रहा है फिर से कोशिश करें
+0

मुझे एक ही समस्या का अनुभव हुआ, लेकिन 'अपाचे' और 'टोमकैट' को पुनरारंभ करने से इस समस्या का समाधान हुआ। क्या इसका मतलब यह है कि 'मूल सर्वर', जिसे मैं मान रहा हूं वह मेरा वेब सर्वर है, HTTP अनुरोधों को धीमा कर रहा है? –

+5

इसका मतलब है कि मूल सर्वर (डेटा वाला वेब सर्वर) प्रॉक्सी (इंटरमीडिएट सर्वर जो आपकी ओर से मूल सर्वर तक पहुंचने का प्रयास कर रहा है) के लिए बहुत धीमा था। –

1

यदि आपका का उपयोग कर ASP.Net 5 (अब ASP.Net कोर v1 के रूप में जाना जाता है) अपने project.json में सुनिश्चित "आदेश" प्रत्येक साइट होस्ट कर रहे हैं कि प्रकार का छोटा बाज प्रॉक्सी सुन बंदरगाह साइटों के बीच अलग के लिए खंड, अन्यथा एक साइट काम करेगी लेकिन दूसरा 504 गेटवे टाइमआउट लौटाएगा।

"commands": { 
    "web": "Microsoft.AspNet.Server.Kestrel --server.urls http://localhost:5090" 
    }, 
1

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

2

मान लीजिए कि प्रॉक्सी सर्वर ए (उदाहरण के लिए nginx) तक पहुंच है, और सर्वर ए किसी अन्य सर्वर बी (उदाहरण के लिए टोमकैट) के अनुरोध को अग्रेषित करता है।

यदि यह प्रक्रिया लंबे समय तक जारी रहती है (प्रॉक्सी सर्वर से अधिक टाइमआउट सेटिंग पढ़ने के लिए), ए को अभी भी बी की पूर्ण प्रतिक्रिया नहीं मिली है। ऐसा होता है।

nginx के लिए, आप प्रॉक्सी_read_timeout (स्थान में) संपत्ति को हल करने के लिए कॉन्फ़िगर कर सकते हैं। लेकिन यह आमतौर पर एक अच्छा विचार नहीं है, यदि आप मान को बहुत अधिक सेट करते हैं। यह वास्तविक त्रुटि को छुपा सकता है। आप इस समस्या को वास्तव में हल करने के लिए डिज़ाइन में बेहतर सुधार करेंगे।

संबंधित मुद्दे