504 गेटवे टाइम आउट

Apigee Edge का दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं. जानकारी

समस्या का ब्यौरा

एपीआई कॉल के जवाब के तौर पर, क्लाइंट ऐप्लिकेशन को 504 एचटीटीपी स्टेटस कोड के साथ मैसेज Gateway Timeout मिलता है.

एचटीटीपी स्टेटस कोड - 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 में टाइम आउट होने की वजहों के बारे में ज़्यादा जानकारी दी गई है:

टाइम आउट होने की घटना विवरण
मैसेज प्रोसेसर पर टाइम आउट होना
  • बैकएंड सर्वर, मैसेज प्रोसेसर पर तय किए गए टाइम आउट के अंदर मैसेज प्रोसेसर का जवाब नहीं देता.
  • मैसेज प्रोसेसर टाइम आउट हो जाता है और रूटर को जवाब की स्थिति 504 Gateway Timeout के तौर पर भेजता है.
राऊटर पर टाइम आउट होना
  • मैसेज प्रोसेसर, राऊटर पर तय किए गए टाइम आउट के अंदर जवाब नहीं देता.
  • राऊटर का समय खत्म हो जाता है और क्लाइंट ऐप्लिकेशन को जवाब की स्थिति 504 Gateway Timeout के तौर पर भेज देता है.
क्लाइंट ऐप्लिकेशन पर टाइम आउट होता है
  • राउटर, तय किए गए टाइम आउट की अवधि के अंदर क्लाइंट ऐप्लिकेशन का जवाब नहीं देता.
  • क्लाइंट ऐप्लिकेशन टाइम आउट हो जाता है और असली उपयोगकर्ता को जवाब की स्थिति 504 Gateway Timeout के तौर पर दिखती है.

संभावित कारण

Edge में, 504 Gateway Timeout गड़बड़ी की आम वजहें ये हैं:

वजह विवरण इसके लिए चरण बताए गए
धीमा बैकएंड सर्वर एपीआई अनुरोध को प्रोसेस करने वाला बैकएंड सर्वर, बहुत ज़्यादा लोड या खराब परफ़ॉर्मेंस की वजह से बहुत धीमा है. पब्लिक और प्राइवेट क्लाउड के उपयोगकर्ता
Edge की मदद से एपीआई अनुरोध को प्रोसेस करने की धीमी प्रोसेस ज़्यादा लोड या खराब परफ़ॉर्मेंस की वजह से, Edge को एपीआई अनुरोध को प्रोसेस करने में काफ़ी समय लगता है.

धीमा बैकएंड सर्वर

अगर बैकएंड सर्वर बहुत धीमा है या एपीआई अनुरोध को प्रोसेस करने में ज़्यादा समय लगता है, तो आपको 504 Gateway Timeout गड़बड़ी का मैसेज दिखेगा. ऊपर दिए गए सेक्शन में बताया गया है कि टाइम आउट इनमें से किसी एक स्थिति में हो सकता है:

  1. बैकएंड सर्वर के जवाब देने से पहले, मैसेज प्रोसेसर का टाइम आउट हो जाता है.
  2. मैसेज प्रोसेसर/बैकएंड सर्वर के जवाब देने से पहले, राउटर का टाइम आउट हो जाता है.
  3. राउटर/मैसेज प्रोसेसर/बैकएंड सर्वर के जवाब देने से पहले, क्लाइंट ऐप्लिकेशन टाइम आउट हो जाता है.

नीचे दिए गए सेक्शन में, इन सभी स्थितियों में समस्या का पता लगाने और उसे ठीक करने का तरीका बताया गया है.

स्थिति #1 बैकएंड सर्वर से जवाब मिलने से पहले, मैसेज प्रोसेसर टाइम आउट हो जाता है

संक्रमण की जांच

बैकएंड सर्वर के धीमे चलने की वजह से, 504 Gateway Timeout गड़बड़ी हुई है या नहीं, इसका पता लगाने के लिए इन तरीकों का इस्तेमाल करें.

पहला तरीका: ट्रैक का इस्तेमाल करना

अगर समस्या अब भी बनी हुई है (504 गड़बड़ियां अब भी हो रही हैं), तो यह तरीका अपनाएं:

  1. Edge के यूज़र इंटरफ़ेस (यूआई) में, उस एपीआई को ट्रैक करें जिस पर असर पड़ा है. गड़बड़ी होने का इंतज़ार करें या अगर आपके पास एपीआई कॉल है, तो कुछ एपीआई कॉल करें और 504 Gateway Timeout गड़बड़ी को फिर से दिखाएं.
  2. गड़बड़ी होने के बाद, उस अनुरोध की जांच करें जो रिस्पॉन्स कोड को 504 के तौर पर दिखाता है.
  3. हर चरण में बीता हुआ समय देखें और उस चरण को नोट करें जिसमें सबसे ज़्यादा समय बीत रहा है.
  4. अगर आपको यहां दिए गए चरणों में से किसी एक चरण के तुरंत बाद, सबसे ज़्यादा समय बीतने के साथ गड़बड़ी दिखती है, तो इसका मतलब है कि बैकएंड सर्वर धीमा है या अनुरोध को प्रोसेस करने में ज़्यादा समय लग रहा है:
    • टारगेट सर्वर को अनुरोध भेजा गया
    • ServiceCallout की नीति

यहां एक ट्रैक का सैंपल दिया गया है. इससे पता चलता है कि बैकएंड सर्वर ने 55 सेकंड के बाद भी रिस्पॉन्स नहीं दिया, जिसकी वजह से 504 Gateway Timeout गड़बड़ी हुई:

ऊपर दिए गए ट्रेस में, मैसेज प्रोसेसर 55,002 मिलीसेकंड के बाद टाइम आउट हो जाता है, क्योंकि बैकएंड सर्वर जवाब नहीं देता.

प्रक्रिया #2 मैसेज प्रोसेसर लॉग का इस्तेमाल करना

  1. मैसेज प्रोसेसर का लॉग देखें (/opt/apigee/var/log/edge-message-processor/logs/system.log)

  2. अगर आपको किसी खास समय पर, एपीआई प्रॉक्सी अनुरोध के लिए 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=55000ms) के बाद भी जवाब नहीं दिया. इस वजह से, मैसेज प्रोसेसर टाइम आउट हो गया और 504 Gateway Timeout गड़बड़ी का मैसेज भेजा.

    इसे देखें: मैसेज प्रोसेसर पर टाइम आउट को कैसे कंट्रोल किया जाता है?

    • मैसेज प्रोसेसर पर टाइम आउट को कैसे कंट्रोल किया जाता है. आम तौर पर, मैसेज प्रोसेसर HTTPTransport.io.timeout.millis प्रॉपर्टी के ज़रिए, टाइम आउट की डिफ़ॉल्ट वैल्यू 55 सेकंड पर सेट करते हैं. टाइम आउट की यह वैल्यू, उन सभी एपीआई प्रॉक्सी पर लागू होती है जो इस मैसेज प्रोसेसर से सेवा पाने वाले संगठन से जुड़ी हैं.
      • अगर बैकएंड सर्वर 55 सेकंड के अंदर जवाब नहीं देता है, तो मैसेज प्रोसेसर टाइम आउट हो जाता है और क्लाइंट को 504 Gateway Timeout गड़बड़ी का कोड भेजता है.
    • मैसेज प्रोसेसर में बताई गई टाइम आउट वैल्यू को, एपीआई प्रॉक्सी में बताई गई प्रॉपर्टी io.timeout.millis की मदद से ओवरराइड किया जा सकता है. यह टाइम आउट वैल्यू, किसी खास एपीआई प्रोक्सी पर लागू होती है, जिसमें ऊपर बताई गई प्रॉपर्टी तय की गई है. उदाहरण के लिए, अगर io.timeout.millis को एपीआई प्रॉक्सी में 10 सेकंड पर सेट किया गया है, तो इस एपीआई प्रॉक्सी के लिए, टाइम आउट की वैल्यू 10 सेकंड होगी.
      • अगर बैकएंड सर्वर, किसी खास एपीआई प्रॉक्सी के लिए 10 सेकंड के अंदर जवाब नहीं देता है, तो मैसेज प्रोसेसर टाइम आउट हो जाता है और क्लाइंट को 504 Gateway Timeout गड़बड़ी का मैसेज भेजता है.

रिज़ॉल्यूशन

  1. देखें कि बैकएंड सर्वर 55 सेकंड से ज़्यादा समय क्यों ले रहा है. साथ ही, देखें कि क्या इस पर तेज़ी से कार्रवाई करने के लिए इसे ठीक या ऑप्टिमाइज़ किया जा सकता है.
  2. अगर बैकएंड सर्वर को ठीक/ऑप्टिमाइज़ नहीं किया जा सकता या यह पता है कि बैकएंड सर्वर को कॉन्फ़िगर किए गए टाइम आउट से ज़्यादा समय लगता है, तो राउटर और मैसेज प्रोसेसर पर टाइम आउट की वैल्यू को बढ़ाएं.

स्थिति #2 - मैसेज प्रोसेसर/बैकएंड सर्वर के जवाब देने से पहले, राउटर टाइम आउट हो जाता है

अगर मैसेज प्रोसेसर/बैकएंड सर्वर के जवाब देने से पहले राउटर टाइम आउट हो जाता है, तो आपको 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 सेकंड की वैल्यू से बदल दिया जाता है. इसलिए, इस खास एपीआई प्रॉक्सी के लिए, मैसेज प्रोसेसर की टाइम आउट वैल्यू 120 सेकंड होगी.

    एपीआई प्रॉक्सी में सेट की गई 120 सेकंड की तुलना में, राउटर की टाइम आउट वैल्यू (57 सेकंड) कम होती है. इसलिए, अगर बैकएंड सर्वर 57 सेकंड के बाद जवाब नहीं देता है, तो राउटर टाइम आउट हो जाएगा.

संक्रमण की जांच

  1. NGINX ऐक्सेस लॉग देखें (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)

  2. अगर मैसेज प्रोसेसर से पहले राउटर टाइम आउट हो जाता है, तो आपको किसी खास एपीआई अनुरोध के लिए NGINX ऐक्सेस लॉग पर 504 का स्टेटस दिखेगा. साथ ही, मैसेज प्रोसेसर से message id को - के तौर पर सेट किया जाएगा. ऐसा इसलिए होता है, क्योंकि राउटर पर सेट किए गए टाइम आउट की अवधि के अंदर, राउटर को मैसेज प्रोसेसर से कोई जवाब नहीं मिलता.

    राउटर के टाइम आउट होने की वजह से 504 कोड दिखाने वाली NGINX लॉग एंट्री का सैंपल

  3. ऊपर दिए गए उदाहरण में, NGINX पर 504 का स्टेटस देखें. मैसेज प्रोसेसर का मैसेज आईडी - है और कुल समय 57.001 सेकंड है. ऐसा इसलिए हुआ, क्योंकि राउटर 57.001 सेकंड के बाद टाइम आउट हो गया और हमें मैसेज प्रोसेसर से कोई जवाब नहीं मिला.
  4. इस मामले में, आपको मैसेज प्रोसेसर के लॉग में 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-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 exception दिखता है.

ऊपर बताई गई स्थितियों में, यह अपवाद दिख सकता है. इसलिए, 504 Gateway Timeout गड़बड़ी की असल वजह अब भी बैकएंड सर्वर है, जिसे जवाब देने में ज़्यादा समय लगता है और आपको उस समस्या को ठीक करना होगा.

रिज़ॉल्यूशन

  1. अगर यह कस्टम बैकएंड सर्वर है, तो
    1. देखें कि बैकएंड सर्वर को जवाब देने में ज़्यादा समय क्यों लग रहा है. साथ ही, यह भी देखें कि इसे तेज़ी से जवाब देने के लिए ठीक/ऑप्टिमाइज़ किया जा सकता है या नहीं.
    2. अगर बैकएंड सर्वर को ठीक नहीं किया जा सकता या यह ज्ञात है कि बैकएंड सर्वर को ज़्यादा समय लगता है, तो राउटर और मैसेज प्रोसेसर पर टाइम आउट की वैल्यू बढ़ाएं.

      सुझाव: अलग-अलग कॉम्पोनेंट पर टाइम आउट की वैल्यू को इस क्रम में सेट करें:

      क्लाइंट पर टाइम आउट > राऊटर पर टाइम आउट > मैसेज प्रोसेसर पर टाइम आउट > एपीआई प्रॉक्सी में टाइम आउट
  2. अगर यह NodeJS बैकएंड सर्वर है, तो:
    1. देखें कि क्या NodeJS कोड किसी दूसरे बैकएंड सर्वर को कॉल करता है और क्या उसे रिस्पॉन्स देने में ज़्यादा समय लग रहा है. देखें कि बैकएंड सर्वर में ज़्यादा समय क्यों लग रहा है. साथ ही, समस्या को सही तरीके से ठीक करें.
    2. देखें कि क्या मैसेज प्रोसेसर का सीपीयू या मेमोरी का ज़्यादा इस्तेमाल हो रहा है:
      1. अगर किसी मैसेज प्रोसेसर का सीपीयू (CPU) बहुत ज़्यादा इस्तेमाल हो रहा है, तो नीचे दिए गए कमांड का इस्तेमाल करके हर 30 सेकंड में तीन थ्रेड डंप जनरेट करें: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. अगर किसी मैसेज प्रोसेसर में ज़्यादा मेमोरी का इस्तेमाल हो रहा है, तो यहां दिए गए निर्देश का इस्तेमाल करके हीप डंप जनरेट करें: 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. नीचे दिए गए निर्देश का इस्तेमाल करके, मैसेज प्रोसेसर को रीस्टार्ट करें. इससे सीपीयू और मेमोरी का इस्तेमाल कम हो जाएगा: 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. API कॉल को मॉनिटर करके देखें कि समस्या अब भी मौजूद है या नहीं.
      5. Apigee Edge की सहायता टीम से संपर्क करें और /opt/apigee/var/log/edge-message-processor/logs/system.log)ज़्यादा सीपीयू/मेमोरी इस्तेमाल होने की वजह की जांच करने में मदद करने के लिए, /opt/apigee/var/log/edge-message-processor/logs/system.log)थ्रेड डंप, हेप डंप, और मैसेज प्रोसेसर लॉग उपलब्ध कराएं.

यह देखें: मैसेज प्रोसेसर पर NodeJS बैकएंड सर्वर के लिए, टाइम आउट को कैसे कंट्रोल किया जाता है

  • NodeJS बैकएंड सर्वर, मैसेज प्रोसेसर की JVM प्रोसेस में चलता है. nodejs.properties फ़ाइल में मौजूद प्रॉपर्टी http.request.timeout.seconds की मदद से, NodeJS बैकएंड सर्वर के लिए टाइम आउट की वैल्यू को कंट्रोल किया जाता है. यह प्रॉपर्टी डिफ़ॉल्ट रूप से 0 पर सेट होती है. इसका मतलब है कि इस मैसेज प्रोसेसर से जुड़े संगठन के सभी एपीआई प्रॉक्सी के लिए, टाइम आउट डिफ़ॉल्ट रूप से बंद होता है. इसलिए, अगर NodeJS बैकएंड सर्वर को ज़्यादा समय लगता है, तब भी मैसेज प्रोसेसर टाइम आउट नहीं होगा.
  • हालांकि, अगर NodeJS बैकएंड सर्वर को ज़्यादा समय लगता है और एपीआई के अनुरोध को पूरा होने में 57 सेकंड से ज़्यादा लगते हैं, तो राउटर टाइम आउट हो जाएगा और क्लाइंट को 504 Gateway Timeout वाली गड़बड़ी का मैसेज भेजेगा.

स्थिति #3 - राउटर/मैसेज प्रोसेसर/बैकएंड सर्वर के जवाब देने से पहले, क्लाइंट ऐप्लिकेशन का टाइम आउट हो जाता है

अगर बैकएंड सर्वर के जवाब देने से पहले, क्लाइंट ऐप्लिकेशन का टाइम आउट हो जाता है, तो आपको 504 Gateway Timeout गड़बड़ियां दिख सकती हैं. ऐसा तब हो सकता है, जब:

  1. क्लाइंट ऐप्लिकेशन पर सेट की गई टाइम आउट वैल्यू, टाइम आउट पर सेट की गई वैल्यू से कम है राउटर और मैसेज प्रोसेसर:

    उदाहरण के लिए, अगर टाइम आउट की ये वैल्यू सेट की गई हैं, तो:

    क्लाइंट पर समय खत्म राऊटर पर टाइम आउट मैसेज प्रोसेसर चालू होने का समय खत्म हो गया है
    50 सेकंड 57 सेकंड 55 सेकंड

    इस मामले में, Edge से किए गए एपीआई के अनुरोध का जवाब पाने में लगने वाला कुल समय 50 सेकंड से कम होता है. इसमें एपीआई अनुरोध करने, एज (राउटर, मैसेज प्रोसेसर) से अनुरोध को प्रोसेस करने, बैकएंड सर्वर (अगर लागू हो) को अनुरोध भेजने, बैकएंड से अनुरोध को प्रोसेस करने और जवाब भेजने, एज से जवाब को प्रोसेस करने, और आखिर में उसे क्लाइंट को भेजने में लगने वाला समय शामिल है.

    अगर राऊटर 50 सेकंड के अंदर क्लाइंट का जवाब नहीं देता है, तो क्लाइंट का समय खत्म हो जाएगा और वह राऊटर से कनेक्शन बंद कर देगा. क्लाइंट को रिस्पॉन्स कोड के तौर पर 504 मिलेगा.

    इससे NGINX, 499 का स्टेटस कोड सेट कर देगा. इससे पता चलता है कि क्लाइंट ने कनेक्शन बंद कर दिया है.

संक्रमण की जांच

  1. अगर क्लाइंट ऐप्लिकेशन को राउटर से जवाब मिलने से पहले टाइम आउट हो जाता है, तो वह राउटर से कनेक्शन बंद कर देगा. इस स्थिति में, आपको किसी खास एपीआई अनुरोध के लिए, NGINX के ऐक्सेस लॉग में 499 का स्टेटस कोड दिखेगा.

    स्टेटस कोड 499 दिखाने वाली NGINX लॉग एंट्री का सैंपल

  2. ऊपर दिए गए उदाहरण में, ध्यान दें कि NGINX पर 499 का स्टेटस और बीता हुआ कुल समय 50.001 सेकंड है. इससे पता चलता है कि क्लाइंट 50.001 सेकंड के बाद टाइम आउट हो गया.
  3. इस मामले में, आपको 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>
  4. राऊटर का समय खत्म होने के बाद, मैसेज प्रोसेसर के साथ कनेक्शन बंद हो जाता है. जब मैसेज प्रोसेसर, प्रोसेसिंग पूरी कर लेता है, तो वह राउटर को जवाब लिखने की कोशिश करता है. राऊटर से कनेक्शन पहले ही बंद हो चुका है. इसलिए, आपको मैसेज प्रोसेसर पर Broken Pipe exception मिलेगा.
  5. ऊपर बताई गई स्थितियों के तहत, इस अपवाद की उम्मीद की जाती है. 504 Gateway Timeout गड़बड़ी की असल वजह यह है कि बैकएंड सर्वर को जवाब देने में ज़्यादा समय लगता है और आपको उस समस्या को ठीक करना होता है.

रिज़ॉल्यूशन

  1. अगर यह आपका कस्टम बैकएंड सर्वर है, तो:
    1. बैकएंड सर्वर की जांच करके पता लगाएं कि इसमें 57 सेकंड से ज़्यादा समय क्यों लग रहा है. साथ ही, यह भी देखें कि इसे ठीक करके/ऑप्टिमाइज़ करके, तेज़ी से जवाब दिया जा सकता है या नहीं.
    2. अगर बैकएंड सर्वर को ठीक नहीं किया जा सकता या आपको पता है कि बैकएंड सर्वर को ज़्यादा समय लगेगा, तो राउटर और मैसेज प्रोसेसर पर टाइम आउट की वैल्यू बढ़ाएं.

      सुझाव: अलग-अलग कॉम्पोनेंट पर टाइम आउट की वैल्यू को इस क्रम में सेट करें:

      क्लाइंट पर टाइम आउट > राऊटर पर टाइम आउट > मैसेज प्रोसेसर पर टाइम आउट > एपीआई प्रॉक्सी में टाइम आउट
  2. अगर यह NodeJS बैकएंड है, तो:
    1. देखें कि क्या NodeJS कोड किसी दूसरे बैकएंड सर्वर को कॉल करता है और क्या उसे रिटर्न होने में ज़्यादा समय लग रहा है. देखें कि उन बैकएंड सर्वर को ज़्यादा समय क्यों लग रहा है.
    2. देखें कि क्या मैसेज प्रोसेसर का सीपीयू या मेमोरी का ज़्यादा इस्तेमाल हो रहा है:
      1. अगर किसी मैसेज प्रोसेसर को सीपीयू का ज़्यादा इस्तेमाल हो रहा है, तो इस निर्देश का इस्तेमाल करके हर 30 सेकंड में तीन थ्रेड डंप जनरेट करें: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. अगर किसी मैसेज प्रोसेसर के लिए मेमोरी का ज़्यादा इस्तेमाल हो रहा है, तो इस निर्देश का इस्तेमाल करके हीप डंप जनरेट करें: 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. नीचे दिए गए निर्देश का इस्तेमाल करके, मैसेज प्रोसेसर को रीस्टार्ट करें. इससे सीपीयू और मेमोरी कम हो जाएगी: 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. API कॉल को मॉनिटर करके देखें कि समस्या अब भी मौजूद है या नहीं.
      5. Apigee Edge की सहायता टीम से संपर्क करें और उन्हें /opt/apigee/var/log/edge-message-processor/logs/system.log)ज़्यादा सीपीयू/मेमोरी खर्च होने की वजह की जांच करने में मदद करने के लिए, धागे के डंप, हेप डंप, और मैसेज प्रोसेसर लॉग दें.

टाइम आउट की वैल्यू को ज़्यादा करें राऊटर और मैसेज प्रोसेसर पर

अपनी ज़रूरतों के हिसाब से, राउटर और मैसेज प्रोसेसर पर सेट की जाने वाली टाइम आउट वैल्यू को ध्यान से चुनें. टाइम आउट की वैल्यू बहुत ज़्यादा न सेट करें. अगर आपको मदद चाहिए, तो Apigee Edge की सहायता टीम से संपर्क करें.

राऊटर

chown apigee:apigee /opt/apigee/customer/application/router.properties
  1. अगर /opt/apigee/customer/application/router.properties फ़ाइल पहले से मौजूद नहीं है, तो राऊटर मशीन पर इसे बनाएं.
  2. इस फ़ाइल में यह लाइन जोड़ें: 
    conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

    उदाहरण के लिए, अगर आपको टाइम आउट की वैल्यू 120 सेकंड पर सेट करनी है, तो इसे इस तरह सेट करें:

    conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
  3. पक्का करें कि इस फ़ाइल का मालिकाना हक apigee के पास हो:
  4. राऊटर को रीस्टार्ट करें: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  5. अगर आपके पास एक से ज़्यादा राऊटर हैं, तो ऊपर दिया गया तरीका सभी राऊटर पर दोहराएं.

मैसेज प्रोसेसर

  1. अगर /opt/apigee/customer/application/message-processor.properties फ़ाइल पहले से मौजूद नहीं है, तो मैसेज प्रोसेसर मशीन पर इसे बनाएं.
  2. इस फ़ाइल में यह लाइन जोड़ें: 
    conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

    उदाहरण के लिए, अगर आपको टाइम आउट की वैल्यू 120 सेकंड पर सेट करनी है, तो इसे इस तरह सेट करें:

    conf_http_HTTPTransport.io.timeout.millis=120000
  3. पक्का करें कि इस फ़ाइल का मालिकाना हक apigee के पास हो: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. मैसेज प्रोसेसर को रीस्टार्ट करें: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. अगर आपके पास एक से ज़्यादा मैसेज प्रोसेसर हैं, तो ऊपर दिया गया तरीका सभी मैसेज प्रोसेसर पर दोहराएं.

सुझाव: अलग-अलग कॉम्पोनेंट पर टाइम आउट की वैल्यू को इस क्रम में सेट करें:

क्लाइंट पर टाइम आउट > राउटर पर टाइम आउट > मैसेज प्रोसेसर पर टाइम आउट > एपीआई प्रॉक्सी में टाइम आउट

Edge की मदद से एपीआई अनुरोध को प्रोसेस करने में लगने वाला समय ज़्यादा होना

अगर Edge बहुत धीमा है और/या एपीआई अनुरोध को प्रोसेस करने में काफ़ी समय लग रहा है, तो आपको 504 Gateway Timeout गड़बड़ी का मैसेज दिखेगा.

संक्रमण की जांच

  1. Edge के यूज़र इंटरफ़ेस (यूआई) में, उस एपीआई को ट्रैक करें जिस पर असर पड़ा है.
  2. गड़बड़ी के होने का इंतज़ार करें या एपीआई कॉल होने का इंतज़ार करें. इसके बाद, कुछ एपीआई कॉल करें और 504 Gateway Timeout गड़बड़ी के बारे में फिर से बताएं.
  3. ध्यान दें, इस मामले में आपको ट्रैक में 'सही जवाब मिला' दिख सकता है.
    1. मैसेज प्रोसेसर, राउटर/क्लाइंट पर तय किए गए टाइम आउट की अवधि के अंदर जवाब नहीं देता. इसलिए, राउटर/क्लाइंट टाइम आउट हो जाता है. हालांकि, मैसेज प्रोसेसर अनुरोध को प्रोसेस करना जारी रखता है और हो सकता है कि वह इसे प्रोसेस कर पाए.
    2. इसके अलावा, मैसेज प्रोसेसर पर सेट की गई HTTPTransport.io.timeout.millis वैल्यू सिर्फ़ तब ट्रिगर होती है, जब मैसेज प्रोसेसर किसी एचटीटीपी/एचटीटीपीएस बैकएंड सर्वर से संपर्क करता है. दूसरे शब्दों में, जब एपीआई प्रॉक्सी में ServiceCallout नीति के अलावा किसी अन्य नीति को लागू होने में ज़्यादा समय लगेगा, तो यह टाइम आउट ट्रिगर नहीं होगा.
  4. गड़बड़ी होने के बाद, उस अनुरोध की जांच करें जिसे सबसे ज़्यादा समय लगा.
  5. हर चरण में बीता हुआ समय देखें और उस चरण को नोट करें जिसमें सबसे ज़्यादा समय बीत रहा है.
  6. अगर आपको सेवा कॉलआउट नीति के अलावा किसी दूसरी नीति में सबसे ज़्यादा समय बीतता हुआ दिखता है, तो इसका मतलब है कि Edge को अनुरोध को प्रोसेस करने में ज़्यादा समय लग रहा है.
  7. यहां यूज़र इंटरफ़ेस (यूआई) के एक सैंपल ट्रेस की इमेज दी गई है. इसमें JavaScript नीति के तहत, बहुत ज़्यादा समय बीतने की जानकारी दी गई है:

  8. ऊपर दिए गए उदाहरण में, आपने देखा है कि JavaScript नीति में असामान्य रूप से, ~ 245 सेकंड का समय लगता है.

रिज़ॉल्यूशन

  1. देखें कि जिस नीति के जवाब में ज़्यादा समय लगा है वह कौनसी है. साथ ही, यह भी देखें कि क्या कोई ऐसा कस्टम कोड है जिसे प्रोसेस करने में ज़्यादा समय लग सकता है. अगर आपको ऐसा कोई कोड मिलता है, तो देखें कि उस कोड को ठीक या ऑप्टिमाइज़ किया जा सकता है या नहीं.
  2. अगर कोई ऐसा कस्टम कोड नहीं है जिसकी वजह से प्रोसेसिंग में ज़्यादा समय लग सकता है, तो देखें कि मैसेज प्रोसेसर में सीपीयू या मेमोरी का ज़्यादा इस्तेमाल हो रहा है या नहीं:
    1. अगर किसी मैसेज प्रोसेसर का सीपीयू (CPU) बहुत ज़्यादा इस्तेमाल हो रहा है, तो यहां दिए गए कमांड का इस्तेमाल करके हर 30 सेकंड में तीन थ्रेड डंप जनरेट करें: 
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. अगर किसी मैसेज प्रोसेसर का मेमोरी इस्तेमाल बहुत ज़्यादा है, तो यहां दिए गए निर्देश का इस्तेमाल करके, हीप डंप जनरेट करें: 
      sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
    3. नीचे दिए गए निर्देश का इस्तेमाल करके, मैसेज प्रोसेसर को रीस्टार्ट करें. इससे सीपीयू और मेमोरी का इस्तेमाल कम हो जाएगा. 
      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
    4. एपीआई कॉल को मॉनिटर करें और पुष्टि करें कि समस्या अब भी मौजूद है या नहीं.
    5. Apigee Edge की सहायता टीम से संपर्क करें और थ्रेड डंप, ढेर डंप, और मैसेज प्रोसेसर लॉग दें. इससे, /opt/apigee/var/log/edge-message-processor/logs/system.log)सीपीयू/मेमोरी के ज़्यादा इस्तेमाल की वजह का पता लगाने में मदद मिलेगी.

एपीआई मॉनिटरिंग का इस्तेमाल करके समस्याओं का पता लगाना

एपीआई मॉनिटरिंग की मदद से, समस्या वाले हिस्सों को तुरंत अलग किया जा सकता है. इससे गड़बड़ी, परफ़ॉर्मेंस, और इंतज़ार की अवधि से जुड़ी समस्याओं और उनके सोर्स का पता लगाया जा सकता है. जैसे, डेवलपर ऐप्लिकेशन, एपीआई प्रॉक्सी, बैकएंड टारगेट या एपीआई प्लैटफ़ॉर्म.

उदाहरण के तौर पर दिए गए उदाहरण देखें. इसमें, एपीआई मॉनिटरिंग का इस्तेमाल करके, आपके एपीआई की 5xx समस्याओं को हल करने का तरीका बताया गया है. उदाहरण के लिए, हो सकता है कि आप 504 स्टेटस कोड की संख्या किसी खास थ्रेशोल्ड से ज़्यादा होने पर सूचना पाने के लिए, सूचना सेट अप करना चाहें.