Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं. जानकारी
समस्या का ब्यौरा
क्लाइंट ऐप्लिकेशन को एपीआई कॉल के रिस्पॉन्स के तौर पर,
Gateway Timeout
मैसेज के साथ 504
का एचटीटीपी स्टेटस कोड मिलता है.
एचटीटीपी स्टेटस कोड - 504 Gateway Timeout
गड़बड़ी से पता चलता है कि एपीआई चलाने के दौरान क्लाइंट को Edge गेटवे या बैकएंड सर्वर से समय पर जवाब नहीं मिला
गड़बड़ी के मैसेज
क्लाइंट ऐप्लिकेशन को यह रिस्पॉन्स कोड मिलता है:
HTTP/1.1 504 Gateway Timeout
कुछ मामलों में, गड़बड़ी का यह मैसेज भी दिख सकता है:
{ "fault": { "faultstring": "Gateway Timeout", "detail": { "errorcode": "messaging.adaptors.http.flow.GatewayTimeout" } } }
गेटवे टाइम आउट की वजह क्या है?
Edge प्लैटफ़ॉर्म से एपीआई अनुरोध के लिए सामान्य पाथ क्लाइंट -> राऊटर -> मैसेज प्रोसेसर -> बैकएंड सर्वर होगा:
Edge प्लैटफ़ॉर्म में क्लाइंट ऐप्लिकेशन, राऊटर, और मैसेज प्रोसेसर को
सही टाइम आउट वैल्यू के साथ सेट अप किया गया है. Edge प्लैटफ़ॉर्म चाहता है कि टाइम आउट वैल्यू के आधार पर,
हर एपीआई अनुरोध के लिए एक तय समय के अंदर जवाब भेजा जाए. अगर आपको तय समय में जवाब नहीं मिलता है, तो 504 Gateway Timeout Error
वापस कर दिया जाता है.
इस टेबल में इस बारे में ज़्यादा जानकारी दी गई है कि Edge में टाइम आउट कब हो सकते हैं:
समय खत्म होने की फ़्रीक्वेंसी | ब्यौरा |
---|---|
मैसेज प्रोसेसर पर टाइम आउट हो रहा है |
|
राऊटर पर टाइम आउट हो गया |
|
क्लाइंट ऐप्लिकेशन पर समय खत्म हो गया |
|
संभावित कारण
Edge में, 504 Gateway Timeout
गड़बड़ी की सामान्य वजहें ये हैं:
वजह | ब्यौरा | इसके लिए दिए गए चरण |
---|---|---|
धीमा बैकएंड सर्वर | एपीआई अनुरोध को प्रोसेस करने वाला बैकएंड सर्वर बहुत धीमा है. ऐसा बहुत ज़्यादा लोड होने या उसकी परफ़ॉर्मेंस खराब होने की वजह से हुआ है. | सार्वजनिक और निजी क्लाउड के उपयोगकर्ता |
Edge से, एपीआई अनुरोध को प्रोसेस करने में ज़्यादा समय लग रहा है | बहुत ज़्यादा लोड या खराब परफ़ॉर्मेंस की वजह से, Edge को एपीआई अनुरोध को प्रोसेस करने में ज़्यादा समय लगता है. |
धीमा बैकएंड सर्वर
अगर बैकएंड सर्वर बहुत धीमा है या एपीआई के अनुरोध को प्रोसेस करने में ज़्यादा समय लेता है, तो आपको 504 Gateway Timeout
गड़बड़ी दिखेगी. जैसा कि ऊपर दिए गए सेक्शन में बताया गया है, टाइम आउट
इनमें से किसी एक स्थिति में हो सकता है:
- बैकएंड सर्वर के जवाब देने से पहले, मैसेज प्रोसेसर का समय खत्म हो गया.
- मैसेज प्रोसेसर/बैकएंड सर्वर से जवाब देने से पहले राऊटर का समय खत्म हो जाता है.
- राऊटर/मैसेज प्रोसेसर/बैकएंड सर्वर के जवाब देने से पहले क्लाइंट ऐप्लिकेशन का टाइम आउट हो जाता है.
यहां दिए गए सेक्शन में, इनमें से हर स्थिति में समस्या का पता लगाने और उसे ठीक करने का तरीका बताया गया है.
स्थिति #1 बैकएंड सर्वर के जवाब देने से पहले ही मैसेज प्रोसेसर का समय खत्म हो जाना
संक्रमण की जांच
अगर बैकएंड सर्वर धीमा होने की वजह से 504 Gateway Timeout
गड़बड़ी हुई है, तो इन तरीकों का इस्तेमाल करके पता लगाया जा सकता है.
प्रक्रिया #1 ट्रेस का इस्तेमाल करना
अगर समस्या अब भी चालू है (504
गड़बड़ियां अब भी आ रही हैं), तो यह
तरीका अपनाएं:
- Edge यूज़र इंटरफ़ेस (यूआई) में उस एपीआई को ट्रेस करें जिस पर असर हुआ है. गड़बड़ी होने का इंतज़ार करें या
एपीआई कॉल करें. इसके बाद, कुछ एपीआई कॉल करें और
504 Gateway Timeout
गड़बड़ी को फिर से दिखाएं. - गड़बड़ी होने के बाद, रिस्पॉन्स कोड को
504
के तौर पर दिखाने वाले अनुरोध की जांच करें. - हर चरण में बिताए गए समय की जांच करें और उस चरण को नोट करें जिसमें ज़्यादा समय बीतता है.
- अगर आपको यहां दिए गए किसी चरण के तुरंत बाद, सबसे ज़्यादा समय बीतने वाली गड़बड़ी दिखती है, तो इसका मतलब है कि बैकएंड सर्वर धीमा है या अनुरोध को प्रोसेस करने में ज़्यादा समय ले रहा है:
- टारगेट सर्वर को अनुरोध भेजा गया
- सेवा कॉलआउट की नीति
यहां एक सैंपल ट्रेस दिया गया है, जो दिखाता है कि बैकएंड सर्वर ने 55 सेकंड के बाद भी जवाब नहीं दिया,
जिसकी वजह से 504 Gateway Timeout
गड़बड़ी हो रही है:
ऊपर दिए गए ट्रेस में, 55002 मि॰से॰ के बाद मैसेज प्रोसेसर का समय खत्म हो जाता है, क्योंकि बैकएंड सर्वर कोई जवाब नहीं देता.
प्रक्रिया #2 मैसेज प्रोसेसर लॉग का इस्तेमाल करना
- मैसेज प्रोसेसर का लॉग देखें
(
/opt/apigee/var/log/edge-message-processor/logs/system.log
) -
अगर आपको किसी खास समय पर किसी एपीआई प्रॉक्सी अनुरोध के लिए
Gateway Timeout
औरonTimeoutRead
गड़बड़ियां मिलती हैं, तो इसका मतलब है कि मैसेज प्रोसेसर का समय खत्म हो गया है.गेटवे टाइम आउट की गड़बड़ी दिखाने वाला सैंपल मैसेज प्रोसेसर लॉग
2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() : AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway Timeout) 2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() : SSLClientChannel[C:XX.XX.XX.XX:443 Remote host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0 bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead
ऊपर दिए गए मैसेज प्रोसेसर लॉग में, आपको पता चलता है कि XX.XX.XX.XX आईपी पते वाले बैकएंड सर्वर ने 55 सेकंड (lastIO=55000मि॰से॰) के बाद भी कोई जवाब नहीं दिया है. इस वजह से, मैसेज प्रोसेसर का समय खत्म हो गया और
504 Gateway Timeout
गड़बड़ी भेजी गई.इसे देखें: Message प्रोसेसर पर टाइम आउट कैसे कंट्रोल किया जाता है?
- Message प्रोसेसर पर टाइम आउट कैसे कंट्रोल किया जाता है. आम तौर पर, मैसेज प्रोसेसर
HTTPTransport.io.timeout.millis
प्रॉपर्टी के ज़रिए, 55 सेकंड की डिफ़ॉल्ट टाइम आउट वैल्यू के साथ सेट होते हैं. यह टाइम आउट मान उन सभी एपीआई प्रॉक्सी के लिए लागू होता है जो इस मैसेज प्रोसेसर से सेवा देने वाले संगठन से जुड़े हैं.- अगर बैकएंड सर्वर 55 सेकंड के अंदर जवाब नहीं देता, तो मैसेज
प्रोसेसर का टाइम आउट हो जाता है और क्लाइंट को
504 Gateway Timeout
गड़बड़ी भेजी जाती है.
- अगर बैकएंड सर्वर 55 सेकंड के अंदर जवाब नहीं देता, तो मैसेज
प्रोसेसर का टाइम आउट हो जाता है और क्लाइंट को
- मैसेज प्रोसेसर में तय की गई टाइम आउट वैल्यू को एपीआई प्रॉक्सी में बताई गई
io.timeout.millis
प्रॉपर्टी से बदला जा सकता है. यह टाइम आउट वैल्यू उस खास एपीआई प्रॉक्सी पर लागू होती है जिसमें ऊपर बताई गई प्रॉपर्टी के बारे में बताया गया है. उदाहरण के लिए, अगर एपीआई प्रॉक्सी मेंio.timeout.millis
को 10 सेकंड पर सेट किया गया है, तो इस खास एपीआई प्रॉक्सी के लिए, 10 सेकंड की टाइम आउट वैल्यू का इस्तेमाल किया जाएगा.- अगर बैकएंड सर्वर, किसी खास एपीआई प्रॉक्सी के लिए 10 सेकंड के अंदर जवाब नहीं देता, तो मैसेज प्रोसेसर टाइम आउट हो जाता है और क्लाइंट को
504 Gateway Timeout
गड़बड़ी भेजता है.
- अगर बैकएंड सर्वर, किसी खास एपीआई प्रॉक्सी के लिए 10 सेकंड के अंदर जवाब नहीं देता, तो मैसेज प्रोसेसर टाइम आउट हो जाता है और क्लाइंट को
- Message प्रोसेसर पर टाइम आउट कैसे कंट्रोल किया जाता है. आम तौर पर, मैसेज प्रोसेसर
रिज़ॉल्यूशन
- देखें कि बैकएंड सर्वर को 55 सेकंड से ज़्यादा समय क्यों लग रहा है. साथ ही, देखें कि क्या इसे ठीक/ऑप्टिमाइज़ किया जा सकता है, ताकि तेज़ी से जवाब दिया जा सके.
- अगर बैकएंड सर्वर को ठीक या ऑप्टिमाइज़ नहीं किया जा सकता या यह पता हो कि बैकएंड सर्वर को कॉन्फ़िगर किए गए टाइम आउट से ज़्यादा समय लगता है, तो राऊटर और मैसेज प्रोसेसर पर टाइम आउट की वैल्यू को बढ़ाकर सही वैल्यू पर सेट करें.
स्थिति #2 - मैसेज प्रोसेसर/बैकएंड सर्वर से जवाब देने से पहले राऊटर का समय खत्म हो जाता है
अगर Message
प्रोसेसर/बैकएंड सर्वर के जवाब देने से पहले राऊटर का समय खत्म हो जाता है, तो आपको 504 Gateway Timeout
गड़बड़ियां दिख सकती हैं. ऐसा इनमें से किसी एक स्थिति में हो सकता है:
- राऊटर पर सेट किया गया टाइम आउट मान, मैसेज प्रोसेसर पर सेट किए गए टाइम आउट मान से कम होता है. उदाहरण के लिए, मान लें कि राऊटर पर टाइम आउट 50 सेकंड है और मैसेज प्रोसेसर की अवधि 55 सेकंड है.
राऊटर पर टाइम आउट हो गया मैसेज प्रोसेसर पर टाइम आउट हो गया 50 सेकंड 55 सेकंड - मैसेज प्रोसेसर पर मौजूद टाइम आउट वैल्यू को, एपीआई प्रॉक्सी के टारगेट एंडपॉइंट कॉन्फ़िगरेशन में सेट की गई
io.timeout.millis
प्रॉपर्टी का इस्तेमाल करके, ज़्यादा टाइम आउट वैल्यू से बदल दिया जाता है:उदाहरण के लिए, अगर नीचे दी गई टाइम आउट वैल्यू सेट की गई हैं:
राऊटर पर टाइम आउट हो गया मैसेज प्रोसेसर पर टाइम आउट हो गया एपीआई प्रॉक्सी में टाइम आउट हो गया 57 सेकंड 55 सेकंड 120 सेकंड हालांकि, एपीआई प्रॉक्सी में
io.timeout.millis
को 120 सेकंड पर सेट किया गया है:<HTTPTargetConnection> <Properties> <Property name="io.timeout.millis">120000</Property> </Properties> <URL>http://www.apigee.com</URL> </HTTPTargetConnection>
फिर, मैसेज प्रोसेसर को 55 सेकंड के बाद टाइम आउट नहीं किया जाएगा. भले ही, इसकी टाइम आउट वैल्यू (55 सेकंड), राऊटर पर टाइम आउट वैल्यू (57 सेकंड) से कम हो. ऐसा इसलिए होता है, क्योंकि मैसेज प्रोसेसर पर 55 सेकंड की टाइम आउट वैल्यू, एपीआई प्रॉक्सी में सेट की गई 120 सेकंड की वैल्यू से बदल जाती है. इसलिए, इस खास एपीआई प्रॉक्सी के लिए Message प्रोसेसर की टाइम आउट वैल्यू 120 सेकंड की होगी.
एपीआई प्रॉक्सी में 120 सेकंड का टाइम आउट सेट होता है, इसलिए राऊटर की टाइम आउट वैल्यू 57 सेकंड से कम होती है. इसलिए, अगर बैकएंड सर्वर 57 सेकंड के बाद भी जवाब नहीं देता, तो राऊटर टाइम आउट हो जाएगा.
संक्रमण की जांच
- NGINX के ऐक्सेस लॉग की जांच करना
(
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
) -
अगर मैसेज प्रोसेसर से पहले राऊटर आउट हो जाता है, तो आपको एपीआई अनुरोध के लिए NGINX ऐक्सेस लॉग पर
504
की स्थिति दिखेगी. साथ ही, मैसेज प्रोसेसर केmessage id
को-
के तौर पर सेट कर दिया जाएगा. ऐसा इसलिए होता है, क्योंकि राऊटर पर सेट की गई टाइम आउट अवधि के अंदर राऊटर को मैसेज प्रोसेसर से कोई जवाब नहीं मिलता.राउटर का समय खत्म होने की वजह से, 504 कोड वाली NGINX लॉग एंट्री का सैंपल
- ऊपर दिए गए उदाहरण में, NGINX पर
504
की स्थिति पर ध्यान दें. मैसेज प्रोसेसर से मिला मैसेज आईडी-
है और कुल समय 57.001 सेकंड है. इसकी वजह यह है कि राऊटर 57.001 सेकंड बाद टाइम आउट हो गया और हमें मैसेज प्रोसेसर से कोई जवाब नहीं मिला. - इस मामले में, आपको मैसेज प्रोसेसर लॉग (
/opt/apigee/var/log/edge-message-processor/logs/system.log).
2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms lastIO=0ms ) 2017-06-09 00:00:25,887 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace: java.io.IOException: Broken pipe at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na] … <snipped>
में) मेंBroken Pipe
अपवाद दिखेंगे
यह गड़बड़ी इसलिए दिखती है, क्योंकि राऊटर का टाइम आउट होते ही,
Message प्रोसेसर से कनेक्शन बंद कर दिया जाता है. जब मैसेज प्रोसेसर अपनी प्रोसेसिंग पूरी कर लेता है, तो वह राऊटर को जवाब लिखने की कोशिश करता है. राऊटर का कनेक्शन पहले से ही बंद है, इसलिए आपको मैसेज प्रोसेसर पर Broken Pipe exception
मिलेगा.
ऊपर बताई गई परिस्थितियों में यह अपवाद दिख सकता है. इसलिए, 504 Gateway Timeout
गड़बड़ी की असल वजह अब भी बैकएंड सर्वर को जवाब देने में ज़्यादा समय लग रहा है. आपको इस समस्या को ठीक करना होगा.
रिज़ॉल्यूशन
- अगर यह कस्टम बैकएंड सर्वर है, तो
- देखें कि बैकएंड सर्वर, जवाब देने में ज़्यादा समय क्यों ले रहा है. साथ ही, देखें कि क्या इसे ठीक/ऑप्टिमाइज़ किया जा सकता है, ताकि तेज़ी से जवाब दिया जा सके.
- अगर बैकएंड सर्वर को ठीक या ऑप्टिमाइज़ नहीं किया जा सकता या यह आम बात है कि बैकएंड सर्वर को ज़्यादा समय लगता है, तो राउटर और मैसेज प्रोसेसर पर टाइम आउट वैल्यू बढ़ाएं.
आइडिया: अलग-अलग कॉम्पोनेंट पर, टाइम आउट की वैल्यू यहां दिए गए क्रम में सेट करें:
क्लाइंट पर टाइम आउट > राऊटर पर टाइम आउट > मैसेज प्रोसेसर पर टाइम आउट > एपीआई प्रॉक्सी में टाइम आउट
- अगर यह NodeJS बैकएंड सर्वर है, तो:
- देखें कि NodeJS कोड से किसी दूसरे बैकएंड सर्वर को कॉल किया जा रहा है या नहीं. साथ ही, यह भी देखें कि रिस्पॉन्स देने में ज़्यादा समय लग रहा है या नहीं. देखें कि बैकएंड सर्वर ज़्यादा समय क्यों ले रहे हैं. साथ ही, समस्या को जितना हो सके ठीक करें.
- देखें कि क्या मैसेज प्रोसेसर, सीपीयू या मेमोरी का बहुत ज़्यादा इस्तेमाल कर रहे हैं:
- अगर किसी मैसेज प्रोसेसर के लिए सीपीयू का बहुत ज़्यादा इस्तेमाल किया जा रहा है, तो नीचे दिए गए निर्देश का इस्तेमाल करके, हर 30 सेकंड में तीन थ्रेड डंप जनरेट करें:
JAVA_HOME/bin/jstack -l PID > FILENAME
- अगर किसी मैसेज प्रोसेसर के लिए मेमोरी का ज़्यादा इस्तेमाल हो रहा है, तो इस निर्देश का इस्तेमाल करके
हीप
डंप जनरेट करें:
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
- नीचे दिए गए निर्देश का इस्तेमाल करके, मैसेज प्रोसेसर को रीस्टार्ट करें. इससे सीपीयू और मेमोरी
कम हो जाएगी:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- एपीआई कॉल पर नज़र रखें, ताकि यह पक्का किया जा सके कि समस्या अब भी मौजूद है या नहीं.
- Apigee Edge की सहायता टीम से संपर्क करें और
थ्रेड डंप, हीप डंप, और मैसेज प्रोसेसर के लॉग दें
(
/opt/apigee/var/log/edge-message-processor/logs/system.log)
, ताकि सीपीयू/मेमोरी के ज़्यादा इस्तेमाल की वजह का पता लगाने में मदद मिल सके.
- अगर किसी मैसेज प्रोसेसर के लिए सीपीयू का बहुत ज़्यादा इस्तेमाल किया जा रहा है, तो नीचे दिए गए निर्देश का इस्तेमाल करके, हर 30 सेकंड में तीन थ्रेड डंप जनरेट करें:
इसे चुनें: Message प्रोसेसर पर NodeJS बैकएंड सर्वर के लिए, टाइम आउट को कैसे कंट्रोल किया जाता है
|
स्थिति #3 - राऊटर/मैसेज प्रोसेसर/बैकएंड सर्वर के जवाब देने से पहले क्लाइंट ऐप्लिकेशन का समय खत्म हो जाना
अगर बैकएंड सर्वर से जवाब मिलने से पहले क्लाइंट ऐप्लिकेशन का समय खत्म हो जाता है, तो आपको 504 Gateway Timeout
गड़बड़ियां दिख सकती हैं. ऐसा तब हो सकता है, जब:
- क्लाइंट ऐप्लिकेशन पर सेट की गई टाइम आउट वैल्यू, राऊटर और मैसेज प्रोसेसर पर सेट की गई टाइम आउट वैल्यू से कम है:
उदाहरण के लिए, अगर नीचे दी गई टाइम आउट वैल्यू सेट की गई हैं:
क्लाइंट पर समय खत्म हो गया राऊटर पर टाइम आउट हो गया मैसेज प्रोसेसर पर टाइम आउट हो गया 50 सेकंड 57 सेकंड 55 सेकंड इस मामले में, Edge से किए गए किसी एपीआई अनुरोध का जवाब मिलने में लगने वाला कुल समय 50 सेकंड से कम होता है. इसमें, एपीआई अनुरोध को प्रोसेस करने में लगने वाला समय, Edge (Router, Message प्रोसेसर) के ज़रिए प्रोसेस किया जाने वाला अनुरोध, बैकएंड सर्वर को भेजा जाने वाला अनुरोध, बैकएंड, अनुरोध को प्रोसेस करने और जवाब भेजने में, Edge के जवाब को प्रोसेस करने, और आखिर में क्लाइंट को भेजने का समय शामिल है.
अगर राऊटर 50 सेकंड के अंदर क्लाइंट को जवाब नहीं देता, तो क्लाइंट टाइम आउट हो जाएगा और राऊटर के साथ कनेक्शन बंद कर देगा. क्लाइंट को
504
का रिस्पॉन्स कोड मिलेगा.इससे NGINX,
499
का स्टेटस कोड सेट करेगा. इससे पता चलता है कि क्लाइंट ने कनेक्शन बंद कर दिया है.
संक्रमण की जांच
- अगर राऊटर से जवाब मिलने से पहले ही क्लाइंट ऐप्लिकेशन का टाइम आउट हो जाता है, तो राऊटर के साथ क्लाइंट ऐप्लिकेशन का कनेक्शन बंद हो जाएगा. ऐसे में, आपको उस खास एपीआई अनुरोध के लिए, NGINX ऐक्सेस लॉग में 499 का स्टेटस कोड दिखेगा.
NGINX लॉग एंट्री का सैंपल, स्टेटस कोड 499 दिखा रहा है
- ऊपर दिए गए उदाहरण में, ध्यान दें कि NGINX पर
499
की स्थिति और कुल बीता समय 50.001 सेकंड है. इससे पता चलता है कि क्लाइंट का समय 50.001 सेकंड के बाद खत्म हो गया था. - इस मामले में, आपको मैसेज प्रोसेसर लॉग में
Broken Pipe
अपवाद दिखेंगे (/opt/apigee/var/log/edge-message-processor/logs/system.log).
2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms lastIO=0ms ) 2017-06-09 00:00:25,887 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace: java.io.IOException: Broken pipe at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na] … <snipped>
- राऊटर का टाइम आउट होने के बाद, यह मैसेज प्रोसेसर के साथ कनेक्शन को बंद कर देता है. जब
मैसेज प्रोसेसर अपनी प्रोसेसिंग पूरी कर लेता है, तो वह राऊटर को जवाब लिखने की कोशिश करता है.
राऊटर से कनेक्ट करने की सुविधा पहले से ही बंद है, इसलिए आपको मैसेज प्रोसेसर पर
Broken Pipe exception
मिलेगा. - ऊपर बताई गई परिस्थितियों में इस अपवाद की उम्मीद की जाती है. इसलिए,
504 Gateway Timeout
गड़बड़ी की असल वजह यह है कि बैकएंड सर्वर को जवाब देने में ज़्यादा समय लगता है और आपको इस समस्या को ठीक करना पड़ सकता है.
रिज़ॉल्यूशन
- अगर यह आपका कस्टम बैकएंड सर्वर है, तो:
- बैकएंड सर्वर जांच करके पता लगाएं कि इसे 57 सेकंड से ज़्यादा समय क्यों लग रहा है. साथ ही, देखें कि इसे जल्द से जल्द ठीक करने के लिए, ठीक किया जा सकता है या नहीं.
- अगर बैकएंड सर्वर को ठीक या ऑप्टिमाइज़ नहीं किया जा सकता या आपको पता है कि बैकएंड सर्वर को प्रोसेस करने में ज़्यादा समय लगेगा, तो राउटर और मैसेज प्रोसेसर पर टाइम आउट वैल्यू बढ़ाएं.
आइडिया: अलग-अलग कॉम्पोनेंट पर, टाइम आउट की वैल्यू यहां दिए गए क्रम में सेट करें:
क्लाइंट पर टाइम आउट > राऊटर पर टाइम आउट > मैसेज प्रोसेसर पर टाइम आउट > एपीआई प्रॉक्सी में टाइम आउट
- अगर यह NodeJS बैकएंड है, तो:
- देखें कि क्या NodeJS कोड किसी दूसरे बैकएंड सर्वर पर कॉल करता है या नहीं. साथ ही, यह भी देखें कि कॉल को रिटर्न करने में ज़्यादा समय लग रहा है या नहीं. देखें कि उन बैकएंड सर्वर में ज़्यादा समय क्यों लग रहा है.
- देखें कि क्या मैसेज प्रोसेसर, सीपीयू या मेमोरी का बहुत ज़्यादा इस्तेमाल कर रहे हैं:
- अगर किसी मैसेज प्रोसेसर के लिए सीपीयू का बहुत ज़्यादा इस्तेमाल किया जा रहा है, तो नीचे दिए गए निर्देश का इस्तेमाल करके, हर 30 सेकंड में तीन थ्रेड डंप जनरेट करें:
JAVA_HOME/bin/jstack -l PID > FILENAME
- अगर किसी मैसेज प्रोसेसर के लिए मेमोरी का ज़्यादा इस्तेमाल किया जा रहा है, तो इस निर्देश का इस्तेमाल करके
हीप डंप
जनरेट करें:
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
- नीचे दिए गए निर्देश का इस्तेमाल करके, मैसेज प्रोसेसर को रीस्टार्ट करें. इससे सीपीयू और मेमोरी
बंद हो जाएगी:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- एपीआई कॉल पर नज़र रखें, ताकि यह पक्का किया जा सके कि समस्या अब भी मौजूद है या नहीं.
- Apigee Edge की सहायता टीम से संपर्क करें. साथ ही,
थ्रेड डंप, हीप डंप, और मैसेज प्रोसेसर के लॉग उपलब्ध कराएं
(
/opt/apigee/var/log/edge-message-processor/logs/system.log)
इससे उन्हें सीपीयू/मेमोरी के ज़्यादा इस्तेमाल होने की वजह का पता लगाने में मदद मिलेगी.
- अगर किसी मैसेज प्रोसेसर के लिए सीपीयू का बहुत ज़्यादा इस्तेमाल किया जा रहा है, तो नीचे दिए गए निर्देश का इस्तेमाल करके, हर 30 सेकंड में तीन थ्रेड डंप जनरेट करें:
राऊटर और मैसेज प्रोसेसर पर टाइम आउट वैल्यू बढ़ाएं
अपनी ज़रूरतों के मुताबिक, राऊटर और मैसेज प्रोसेसर पर सेट किए जाने वाले टाइम आउट वैल्यू को सावधानी से चुनें. अपने हिसाब से बड़े टाइम आउट वैल्यू सेट न करें. अगर आपको मदद चाहिए, तो Apigee Edge की सहायता टीम से संपर्क करें.
राऊटर
chown apigee:apigee /opt/apigee/customer/application/router.properties
- अगर राऊटर मशीन पर
/opt/apigee/customer/application/router.properties
फ़ाइल पहले से मौजूद नहीं है, तो उसे बनाएं. - इस फ़ाइल में यह लाइन जोड़ें:
conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS
उदाहरण के लिए, अगर आपको टाइम आउट की वैल्यू 120 सेकंड सेट करनी है, तो इसे इस तरह सेट करें:
conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
- पक्का करें कि इस फ़ाइल का मालिकाना हक एपीआईजी के पास हो:
- राऊटर रीस्टार्ट करें:
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
- अगर आपके पास एक से ज़्यादा राऊटर हैं, तो सभी राऊटर पर ऊपर दिया गया तरीका दोहराएं.
मैसेज प्रोसेसर
- अगर Message प्रोसेसर मशीन पर
/opt/apigee/customer/application/message-processor.properties
फ़ाइल पहले से मौजूद नहीं है, तो उसे बनाएं. - इस फ़ाइल में यह लाइन जोड़ें:
conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS
उदाहरण के लिए, अगर आपको टाइम आउट की वैल्यू 120 सेकंड सेट करनी है, तो इसे इस तरह सेट करें:
conf_http_HTTPTransport.io.timeout.millis=120000
- पक्का करें कि इस फ़ाइल का मालिकाना हक एपीआईजी के पास हो:
chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
- मैसेज प्रोसेसर को रीस्टार्ट करें:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- अगर आपके पास एक से ज़्यादा मैसेज प्रोसेसर हैं, तो सभी मैसेज प्रोसेसर पर ऊपर दिया गया तरीका दोहराएं.
आइडिया: अलग-अलग कॉम्पोनेंट पर, टाइम आउट की वैल्यू यहां दिए गए क्रम में सेट करें:क्लाइंट पर टाइम आउट > राऊटर पर टाइम आउट > मैसेज प्रोसेसर पर टाइम आउट > एपीआई प्रॉक्सी में टाइम आउट |
Edge से, एपीआई अनुरोध प्रोसेस करने की धीमी प्रोसेस
अगर Edge बहुत धीमा है और/या एपीआई अनुरोध को प्रोसेस करने में ज़्यादा समय ले रहा है, तो आपको 504 Gateway Timeout
गड़बड़ी दिखेगी.
संक्रमण की जांच
- Edge यूज़र इंटरफ़ेस (यूआई) में उस एपीआई को ट्रेस करें जिस पर असर हुआ है.
- गड़बड़ी होने का इंतज़ार करें या एपीआई कॉल करें. इसके बाद, कुछ एपीआई कॉल करें और
504 Gateway Timeout
गड़बड़ी को फिर से दिखाएं. - ध्यान दें कि इस मामले में, आपको ट्रेस में सही जवाब दिख सकता है.
- राऊटर/क्लाइंट टाइम आउट हो जाता है, क्योंकि मैसेज प्रोसेसर, राऊटर/क्लाइंट पर तय की गई टाइम आउट अवधि के अंदर जवाब नहीं देता (इनमें से जो भी सबसे कम समय आउट हो). हालांकि, मैसेज प्रोसेसर अनुरोध को प्रोसेस करना जारी रखता है और हो सकता है कि वह सही से पूरा हो जाए.
- इसके अलावा, मैसेज प्रोसेसर पर सेट की गई
HTTPTransport.io.timeout.millis
वैल्यू सिर्फ़ तब ट्रिगर होती है, जब Message प्रोसेसर किसी एचटीटीपी/एचटीटीपीएस बैकएंड सर्वर से कम्यूनिकेट करता हो. दूसरे शब्दों में, एपीआई प्रॉक्सी में मौजूद किसी भी नीति (सर्विसकॉलआउट नीति के अलावा) में ज़्यादा समय लगने पर, यह टाइम आउट ट्रिगर नहीं होगा.
- गड़बड़ी होने के बाद, उस अनुरोध की जांच करें जिसमें सबसे ज़्यादा समय बीत चुका है.
- हर चरण में बीता समय देखें और उस चरण को नोट करें जिसमें सबसे ज़्यादा समय बीतता है.
- अगर आपको सेवा कॉलआउट नीति के अलावा किसी दूसरी नीति में सबसे ज़्यादा समय बीत चुका है, तो इसका मतलब है कि Edge को अनुरोध को प्रोसेस करने में ज़्यादा समय लग रहा है.
- यहां एक सैंपल यूज़र इंटरफ़ेस (यूआई) ट्रेस दिया गया है, जो JavaScript की नीति में बहुत ज़्यादा बीता हुआ समय दिखा रहा है:
- ऊपर दिए गए उदाहरण में, आपने देखा कि JavaScript की नीति को असामान्य तौर पर, ~ 245 सेकंड से ज़्यादा नहीं होना चाहिए.
रिज़ॉल्यूशन
- देखें कि क्या नीति की वजह से जवाब देने में ज़्यादा समय लगा. साथ ही, देखें कि क्या कोई ऐसा कस्टम कोड मौजूद है जिसे प्रोसेस करने में ज़्यादा समय लग सकता है. अगर ऐसा कोई कोड है, तो देखें कि पहचाने गए कोड को ठीक या ऑप्टिमाइज़ किया जा सकता है या नहीं.
- अगर ऐसा कोई कस्टम कोड नहीं है जिसकी वजह से प्रोसेस होने में ज़्यादा समय लग सकता है, तो देखें कि क्या मैसेज
प्रोसेसर, सीपीयू या मेमोरी का ज़्यादा इस्तेमाल कर रहे हैं:
- अगर किसी मैसेज प्रोसेसर के लिए सीपीयू का बहुत ज़्यादा इस्तेमाल किया जा रहा है, तो नीचे दिए गए निर्देश का इस्तेमाल करके, हर 30 सेकंड में तीन थ्रेड डंप जनरेट करें:
JAVA_HOME/bin/jstack -l PID > FILENAME
- अगर किसी मैसेज प्रोसेसर की मेमोरी का इस्तेमाल बहुत ज़्यादा हो रहा है, तो इस निर्देश का इस्तेमाल करके
हीप डंप
जनरेट करें:
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
- नीचे दिए गए निर्देश का इस्तेमाल करके, मैसेज प्रोसेसर को रीस्टार्ट करें. इससे सीपीयू
और मेमोरी कम हो जाएगी.
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- एपीआई कॉल पर नज़र रखें और पुष्टि करें कि समस्या अब भी मौजूद है या नहीं.
- Apigee Edge की सहायता टीम से संपर्क करें. साथ ही, थ्रेड डंप, हीप डंप, और मैसेज प्रोसेसर लॉग की जानकारी दें
(
/opt/apigee/var/log/edge-message-processor/logs/system.log)
, ताकि सीपीयू/मेमोरी के ज़्यादा इस्तेमाल होने की वजह का पता लगाने में उन्हें मदद मिल सके.
- अगर किसी मैसेज प्रोसेसर के लिए सीपीयू का बहुत ज़्यादा इस्तेमाल किया जा रहा है, तो नीचे दिए गए निर्देश का इस्तेमाल करके, हर 30 सेकंड में तीन थ्रेड डंप जनरेट करें:
एपीआई मॉनिटरिंग का इस्तेमाल करके, समस्याओं का पता लगाना
एपीआई मॉनिटरिंग की मदद से, समस्या वाले हिस्सों को तुरंत अलग किया जा सकता है. इससे गड़बड़ियों, परफ़ॉर्मेंस, और इंतज़ार के समय से जुड़ी समस्याओं और उनके सोर्स, जैसे कि डेवलपर ऐप्लिकेशन, एपीआई प्रॉक्सी, बैकएंड टारगेट या एपीआई प्लैटफ़ॉर्म का पता लगाने में मदद मिलती है.
उदाहरण के तौर पर दिए गए उदाहरण को देखें. इसमें, एपीआई मॉनिटरिंग का इस्तेमाल करके, अपने एपीआई की 5xx समस्याओं को हल करने का तरीका बताया गया है. उदाहरण के लिए, हो सकता है कि 504 स्टेटस कोड की संख्या एक खास थ्रेशोल्ड से ज़्यादा हो जाने पर, आपको इसके बारे में सूचना पाने के लिए एक सूचना सेट अप करनी पड़े.