HTTP स्थिति 504

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

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

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

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

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

स्कॉट

0

7 उत्तर

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

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

  • प्रॉक्सी का टाइमआउट मान बढ़ाएं (यदि यह आपके नियंत्रण में है)
  • अपना अनुरोध किसी भिन्न सर्वर पर करें (यदि एक ही डेटा वाला कोई अन्य सर्वर है)
  • अपना अनुरोध अलग-अलग करें (यदि संभव हो) जैसे कि आप एक समय में कम डेटा का अनुरोध कर रहे हैं
  • सर्वर को समस्या नहीं होने के बाद पुनः प्रयास करें
0
जोड़ा
इसका मतलब है कि मूल सर्वर (डेटा वाला वेब सर्वर) प्रॉक्सी (इंटरमीडिएट सर्वर जो आपकी ओर से मूल सर्वर तक पहुंचने का प्रयास कर रहा है) के लिए बहुत धीमा था।
जोड़ा लेखक james.garriss, स्रोत
मैंने एक ही समस्या का अनुभव किया, लेकिन अपाचे और Tomcat को पुनरारंभ करना इस समस्या को हल किया। क्या इसका मतलब यह है कि मूल सर्वर , जो मैं मान रहा हूं वह मेरा वेब सर्वर है, HTTP अनुरोधों को धीमा कर रहा है?
जोड़ा लेखक Kevin Meredith, स्रोत

चेकअपडाउन में 504 त्रुटि का एक अच्छा स्पष्टीकरण है:

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

     

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

     

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

0
जोड़ा

Maybe its about your network proxy settings. Look that http://rapid-i.com/rapidforum/index.php?topic=4436.0

0
जोड़ा

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

 "commands": {
    "web": "Microsoft.AspNet.Server.Kestrel --server.urls http://localhost:5090"
  },
0
जोड़ा

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

0
जोड़ा

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

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

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

0
जोड़ा

मेरे पास एक और मुद्दा है जो मुझे 504 दे रहा है। यह बहुत दूर है लेकिन मैं इसे googlers और posterity के लिए यहां लिखूंगा ...

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

मेरे मामले में मैं किसी अन्य डोमेन में एक सेवा कॉल करने की कोशिश कर रहा था जहां मुझे पता चला कि एक एसपीएन पंजीकृत था। इस तरह: http/myurl.test.local (बस एक उदाहरण)

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

एसपीएन को हटाने और कॉल को एनटीएलएम में वापस आने की इजाजत देने के बाद, यह ठीक काम करता है।

जैसा कि मैंने कहा था ... यह ऐसा कुछ नहीं है जिसमें आप भागने की संभावना रखते हैं, क्योंकि अधिकांश संगठन दो डोमेन के बीच ऐसे चुनिंदा ट्रस्ट नहीं लेते हैं ... लेकिन यह 504 देता है और मुझे कुछ (अधिक) ग्रे हेयर ।

0
जोड़ा