504 গেটওয়ে টাইমআউট

আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশনে যান । তথ্য

উপসর্গ

ক্লায়েন্ট অ্যাপ্লিকেশনটি API কলগুলির প্রতিক্রিয়া হিসাবে Gateway Timeout বার্তা সহ 504 এর একটি HTTP স্ট্যাটাস কোড পায়।

এইচটিটিপি স্ট্যাটাস কোড - 504 Gateway Timeout ত্রুটি নির্দেশ করে যে ক্লায়েন্ট এজ গেটওয়ে বা ব্যাকএন্ড সার্ভার থেকে একটি API কার্যকর করার সময় সময়মত প্রতিক্রিয়া পায়নি

ত্রুটি বার্তা

ক্লায়েন্ট অ্যাপ্লিকেশন নিম্নলিখিত প্রতিক্রিয়া কোড পায়:

HTTP/1.1 504 Gateway Timeout

কিছু ক্ষেত্রে, নিম্নলিখিত ত্রুটি বার্তাটিও লক্ষ্য করা যেতে পারে: 

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

গেটওয়ে টাইমআউটের কারণ কী?

এজ প্ল্যাটফর্মের মাধ্যমে একটি API অনুরোধের জন্য সাধারণ পথটি হবে ক্লায়েন্ট -> রাউটার -> মেসেজ প্রসেসর -> ব্যাকএন্ড সার্ভার যেমন নীচের চিত্রে দেখানো হয়েছে:

এজ প্ল্যাটফর্মের মধ্যে ক্লায়েন্ট অ্যাপ্লিকেশন, রাউটার এবং মেসেজ প্রসেসর উপযুক্ত টাইমআউট মান সহ সেট আপ করা হয়েছে। এজ প্ল্যাটফর্ম আশা করে যে সময়সীমার মানগুলির উপর ভিত্তি করে প্রতিটি API অনুরোধের জন্য একটি নির্দিষ্ট সময়ের মধ্যে একটি প্রতিক্রিয়া পাঠানো হবে। যদি আপনি নির্দিষ্ট সময়ের মধ্যে প্রতিক্রিয়া না পান, তাহলে 504 Gateway Timeout Error ফিরে আসবে।

নিচের সারণীটি এজ-এ কখন টাইমআউট ঘটতে পারে সে সম্পর্কে আরও বিশদ প্রদান করে:

সময় শেষ হওয়ার ঘটনা বিস্তারিত
মেসেজ প্রসেসরে টাইমআউট ঘটে
  • ব্যাকএন্ড সার্ভার মেসেজ প্রসেসরে একটি নির্দিষ্ট সময়সীমার মধ্যে বার্তা প্রসেসরে সাড়া দেয় না।
  • বার্তা প্রসেসরের সময় শেষ হয়ে যায় এবং রাউটারে 504 Gateway Timeout হিসাবে প্রতিক্রিয়া স্থিতি পাঠায়।
রাউটারে টাইমআউট ঘটে
  • বার্তা প্রসেসর রাউটারের নির্দিষ্ট সময়সীমার মধ্যে রাউটারে সাড়া দেয় না।
  • রাউটার টাইম আউট হয়ে যায় এবং ক্লায়েন্ট অ্যাপ্লিকেশনে 504 Gateway Timeout হিসাবে প্রতিক্রিয়া স্থিতি পাঠায়।
ক্লায়েন্ট অ্যাপ্লিকেশনে সময় শেষ হয়
  • রাউটারে নির্দিষ্ট সময়সীমার মধ্যে রাউটার ক্লায়েন্ট অ্যাপ্লিকেশনে সাড়া দেয় না।
  • ক্লায়েন্ট অ্যাপ্লিকেশনের সময় শেষ হয় এবং শেষ ব্যবহারকারীর কাছে 504 Gateway Timeout হিসাবে প্রতিক্রিয়া স্থিতি শেষ হয়।

সম্ভাব্য কারণ

এজে, 504 Gateway Timeout ত্রুটির সাধারণ কারণগুলি হল:

কারণ বিস্তারিত জন্য দেওয়া পদক্ষেপ
ধীর ব্যাকএন্ড সার্ভার যে ব্যাকএন্ড সার্ভারটি API অনুরোধটি প্রক্রিয়া করছে তা উচ্চ লোড বা দুর্বল কর্মক্ষমতার কারণে খুব ধীর। পাবলিক এবং প্রাইভেট ক্লাউড ব্যবহারকারী
এজ দ্বারা ধীর API অনুরোধ প্রক্রিয়াকরণ উচ্চ লোড বা দুর্বল কর্মক্ষমতার কারণে এজ এপিআই অনুরোধ প্রক্রিয়া করতে দীর্ঘ সময় নেয়।

ধীর ব্যাকএন্ড সার্ভার

যদি ব্যাকএন্ড সার্ভারটি খুব ধীর হয় বা API অনুরোধ প্রক্রিয়া করতে দীর্ঘ সময় নেয়, তাহলে আপনি একটি 504 Gateway Timeout ত্রুটি পাবেন। উপরের বিভাগে যেমন ব্যাখ্যা করা হয়েছে, টাইমআউট নিম্নলিখিত পরিস্থিতিতে একটির অধীনে ঘটতে পারে:

  1. ব্যাকএন্ড সার্ভার সাড়া দেওয়ার আগে মেসেজ প্রসেসরের সময় শেষ।
  2. বার্তা প্রসেসর/ব্যাকএন্ড সার্ভার সাড়া দেওয়ার আগে রাউটার টাইম আউট।
  3. রাউটার/মেসেজ প্রসেসর/ব্যাকএন্ড সার্ভার সাড়া দেওয়ার আগে ক্লায়েন্ট অ্যাপ্লিকেশনের সময় শেষ।

নিম্নলিখিত বিভাগগুলি বর্ণনা করে যে এই প্রতিটি পরিস্থিতিতে কীভাবে সমস্যাটি নির্ণয় এবং সমাধান করা যায়।

পরিস্থিতি #1 ব্যাকএন্ড সার্ভার সাড়া দেওয়ার আগে বার্তা প্রসেসরের সময় শেষ

রোগ নির্ণয়

ধীর ব্যাকএন্ড সার্ভারের কারণে 504 Gateway Timeout ত্রুটি ঘটেছে কিনা তা নির্ণয় করতে আপনি নিম্নলিখিত পদ্ধতিগুলি ব্যবহার করতে পারেন।

পদ্ধতি #1 ট্রেস ব্যবহার করে

যদি সমস্যাটি এখনও সক্রিয় থাকে ( 504 ত্রুটি এখনও ঘটছে), তাহলে নীচের পদক্ষেপগুলি অনুসরণ করুন:

  1. এজ UI এ প্রভাবিত API ট্রেস করুন। হয় ত্রুটি হওয়ার জন্য অপেক্ষা করুন অথবা আপনার যদি API কল থাকে, তাহলে কিছু API কল করুন এবং 504 Gateway Timeout ত্রুটিটি পুনরুত্পাদন করুন।
  2. একবার ত্রুটিটি হয়ে গেলে, নির্দিষ্ট অনুরোধটি পরীক্ষা করুন যা প্রতিক্রিয়া কোডটি 504 হিসাবে দেখায়।
  3. প্রতিটি পর্বে অতিবাহিত সময় পরীক্ষা করুন এবং যে পর্যায়ে সবচেয়ে বেশি সময় ব্যয় হয় তার একটি নোট করুন।
  4. আপনি যদি নিম্নলিখিত পর্যায়গুলির মধ্যে একটির পরে অবিলম্বে দীর্ঘতম অতিবাহিত সময়ের সাথে ত্রুটিটি পর্যবেক্ষণ করেন, তবে এটি নির্দেশ করে যে ব্যাকএন্ড সার্ভারটি ধীর গতিতে বা অনুরোধটি প্রক্রিয়া করতে দীর্ঘ সময় নিচ্ছে:
    • টার্গেট সার্ভারে অনুরোধ পাঠানো হয়েছে
    • সার্ভিস কলআউট নীতি

নিম্নলিখিতটি একটি নমুনা ট্রেস প্রদান করে দেখায় যে ব্যাকএন্ড সার্ভার 55 সেকেন্ডের পরেও সাড়া দেয়নি যার ফলে একটি 504 Gateway Timeout ত্রুটি হয়েছে:

উপরের ট্রেসে, ব্যাকএন্ড সার্ভার সাড়া না দেওয়ায় মেসেজ প্রসেসর 55002 ms পরে শেষ হয়ে যায়।

পদ্ধতি #2 মেসেজ প্রসেসর লগ ব্যবহার করে

  1. মেসেজ প্রসেসরের লগ চেক করুন ( /opt/apigee/var/log/edge-message-processor/logs/system.log )

  2. আপনি যদি নির্দিষ্ট সময়ে নির্দিষ্ট API প্রক্সি অনুরোধের জন্য 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 সেকেন্ডের একটি ডিফল্ট টাইমআউট মান সহ সেট করা হয়। এই টাইমআউট মানটি এই মেসেজ প্রসেসর দ্বারা পরিবেশিত একটি সংস্থার অন্তর্গত সমস্ত API প্রক্সিগুলির জন্য প্রযোজ্য৷
      • যদি ব্যাকএন্ড সার্ভার 55 সেকেন্ডের মধ্যে সাড়া না দেয়, তাহলে মেসেজ প্রসেসর টাইম আউট হয়ে যায় এবং ক্লায়েন্টকে 504 Gateway Timeout ত্রুটি পাঠায়।
    • বার্তা প্রসেসরে নির্দিষ্ট সময়সীমার মানটি API প্রক্সির মধ্যে নির্দিষ্ট করা io.timeout.millis বৈশিষ্ট্য দ্বারা ওভাররাইড করা যেতে পারে। এই টাইমআউট মান একটি নির্দিষ্ট API প্রক্সিতে প্রযোজ্য যেখানে উপরে উল্লিখিত সম্পত্তি নির্দিষ্ট করা আছে। উদাহরণস্বরূপ, যদি API প্রক্সির মধ্যে io.timeout.millis 10 সেকেন্ডে সেট করা হয়, তাহলে এই নির্দিষ্ট API প্রক্সির জন্য 10 সেকেন্ডের টাইমআউট মান ব্যবহার করা হবে।
      • যদি ব্যাকএন্ড সার্ভার নির্দিষ্ট API প্রক্সির জন্য 10 সেকেন্ডের মধ্যে সাড়া না দেয়, তাহলে মেসেজ প্রসেসর টাইম আউট হয়ে যায় এবং ক্লায়েন্টকে 504 Gateway Timeout ত্রুটি পাঠায়।

রেজোলিউশন

  1. ব্যাকএন্ড সার্ভারটি কেন 55 সেকেন্ডের বেশি সময় নিচ্ছে তা পরীক্ষা করুন এবং দ্রুত প্রতিক্রিয়া জানাতে এটিকে সংশোধন/অপ্টিমাইজ করা যায় কিনা তা দেখুন।
  2. যদি ব্যাকএন্ড সার্ভার ঠিক করা/অপ্টিমাইজ করা সম্ভব না হয় বা জানা যায় যে ব্যাকএন্ড সার্ভারটি কনফিগার করা টাইমআউটের চেয়ে বেশি সময় নেয়, তাহলে রাউটার এবং মেসেজ প্রসেসরের টাইমআউট মান একটি উপযুক্ত মান বৃদ্ধি করুন ।

দৃশ্য #2 - মেসেজ প্রসেসর/ব্যাকএন্ড সার্ভার সাড়া দেওয়ার আগে রাউটার টাইম আউট

মেসেজ প্রসেসর/ব্যাকএন্ড সার্ভার সাড়া দেওয়ার আগে রাউটার টাইম আউট হলে আপনি 504 Gateway Timeout ত্রুটি পেতে পারেন। এটি নিম্নলিখিত পরিস্থিতিতে একটির অধীনে ঘটতে পারে:

  • রাউটারে সেট করা টাইমআউট মানটি মেসেজ প্রসেসরে সেট করা টাইমআউট মানের চেয়ে ছোট। উদাহরণস্বরূপ, ধরা যাক রাউটারের সময়সীমা 50 সেকেন্ড, যেখানে বার্তা প্রসেসর 55 সেকেন্ড।
    রাউটারে টাইমআউট মেসেজ প্রসেসরে টাইমআউট
    50 সেকেন্ড 55 সেকেন্ড
  • বার্তা প্রসেসরের টাইমআউট মানটি API প্রক্সির টার্গেট এন্ডপয়েন্ট কনফিগারেশনের মধ্যে সেট করা io.timeout.millis প্রপার্টি ব্যবহার করে উচ্চ টাইমআউট মান দিয়ে ওভাররাইড করা হয়:

    উদাহরণস্বরূপ, যদি নিম্নলিখিত টাইমআউট মান সেট করা হয়:

    রাউটারে টাইমআউট মেসেজ প্রসেসরে টাইমআউট API প্রক্সির মধ্যে টাইমআউট
    57 সেকেন্ড 55 সেকেন্ড 120 সেকেন্ড

    কিন্তু io.timeout.millis API প্রক্সিতে 120 সেকেন্ডে সেট করা হয়েছে:

    <HTTPTargetConnection>
     <Properties>
          <Property name="io.timeout.millis">120000</Property>
      </Properties>
      <URL>http://www.apigee.com</URL>
</HTTPTargetConnection>

    তারপর, মেসেজ প্রসেসর 55 সেকেন্ডের পরে টাইমআউট করবে না যদিও এটির টাইমআউট মান (55 সেকেন্ড) রাউটারের টাইমআউট মান (57 সেকেন্ড) থেকে কম। এর কারণ হল মেসেজ প্রসেসরে 55 সেকেন্ডের টাইমআউট মান 120 সেকেন্ডের মান দ্বারা ওভাররাইড করা হয় যা API প্রক্সির মধ্যে সেট করা হয়। তাই এই নির্দিষ্ট API প্রক্সির জন্য মেসেজ প্রসেসরের টাইমআউট মান হবে 120 সেকেন্ড।

    যেহেতু এপিআই প্রক্সির মধ্যে 120 সেকেন্ডের সেটের তুলনায় রাউটারের টাইমআউট মান (57 সেকেন্ড) কম, তাই যদি ব্যাকএন্ড সার্ভার 57 সেকেন্ডের পরেও সাড়া না দেয় তাহলে রাউটারটি টাইমআউট হয়ে যাবে।

রোগ নির্ণয়

  1. NGINX অ্যাক্সেস লগ চেক করুন ( /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log )

  2. যদি রাউটারটি মেসেজ প্রসেসরের আগে টাইম আউট হয়ে যায়, তাহলে আপনি নির্দিষ্ট API অনুরোধের জন্য NGINX অ্যাক্সেস লগগুলিতে 504 এর স্থিতি দেখতে পাবেন এবং মেসেজ প্রসেসর থেকে message id হিসাবে সেট করা হবে - । কারণ রাউটারে সেট করা সময়সীমার মধ্যে রাউটার মেসেজ প্রসেসর থেকে কোনো প্রতিক্রিয়া পায়নি।

    রাউটারের সময় শেষ হওয়ার কারণে নমুনা NGINX লগ এন্ট্রি 504 দেখাচ্ছে

  3. উপরের উদাহরণে, NGINX-এ 504 এর স্থিতি লক্ষ্য করুন, মেসেজ প্রসেসর থেকে বার্তা আইডি হল - এবং মোট সময় অতিবাহিত হয়েছে 57.001 সেকেন্ড৷ কারণ রাউটারটি 57.001 সেকেন্ড পরে টাইম আউট হয়ে গেছে এবং আমরা মেসেজ প্রসেসর থেকে কোনো প্রতিক্রিয়া পাইনি।
  4. এই ক্ষেত্রে, আপনি মেসেজ প্রসেসর লগগুলিতে ( /opt/apigee/var/log/edge-message-processor/logs/system.log). Broken Pipe ব্যতিক্রম দেখতে পাবেন। 
    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. যদি ব্যাকএন্ড সার্ভার ঠিক করা/অপ্টিমাইজ করা সম্ভব না হয় বা এটি একটি পরিচিত সত্য যে ব্যাকএন্ড সার্ভারটি দীর্ঘ সময় নেয়, তাহলে রাউটার এবং মেসেজ প্রসেসরে টাইমআউট মান বাড়ান ।

      আইডিয়া: নিম্নলিখিত ক্রমে বিভিন্ন উপাদানের সময়সীমার মান সেট করুন:

      ক্লায়েন্টের সময়সীমা> রাউটারের সময়সীমা> বার্তা প্রসেসরের সময়সীমা> API প্রক্সির মধ্যে সময় শেষ

  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) উচ্চ CPU/মেমরির কারণ অনুসন্ধানে সহায়তা করতে ব্যবহার

এটি পরীক্ষা করুন: বার্তা প্রসেসরে নোডজেএস ব্যাকএন্ড সার্ভারের জন্য কীভাবে টাইমআউট নিয়ন্ত্রণ করা হয়

  • NodeJS ব্যাকএন্ড সার্ভার মেসেজ প্রসেসরের JVM প্রক্রিয়ার মধ্যে চলে। NodeJS ব্যাকএন্ড সার্ভারের টাইমআউট মান nodejs.properties ফাইলের http.request.timeout.seconds প্রপার্টির মাধ্যমে নিয়ন্ত্রিত হয়। এই বৈশিষ্ট্যটি ডিফল্টরূপে 0 তে সেট করা থাকে, অর্থাৎ, এই মেসেজ প্রসেসর দ্বারা পরিবেশিত একটি সংস্থার অন্তর্গত সমস্ত API প্রক্সিগুলির জন্য টাইমআউট ডিফল্টরূপে নিষ্ক্রিয় থাকে৷ সুতরাং একটি নোডজেএস ব্যাকএন্ড সার্ভার দীর্ঘ সময় নিলেও, মেসেজ প্রসেসর সময় শেষ হবে না।
  • যাইহোক, যদি NodeJS ব্যাকএন্ড সার্ভারটি বেশি সময় নেয় এবং API অনুরোধের সময় যদি 57 সেকেন্ড হয়, তাহলে রাউটার টাইমআউট হবে এবং ক্লায়েন্টকে 504 Gateway Timeout ত্রুটি পাঠাবে।

পরিস্থিতি #3 - রাউটার/মেসেজ প্রসেসর/ব্যাকএন্ড সার্ভার সাড়া দেওয়ার আগে ক্লায়েন্ট অ্যাপ্লিকেশনের সময় শেষ

আপনি 504 Gateway Timeout ত্রুটি পেতে পারেন যদি ক্লায়েন্ট অ্যাপ্লিকেশন ব্যাকএন্ড সার্ভারের প্রতিক্রিয়া জানানোর আগে সময় শেষ হয়ে যায়। এই পরিস্থিতি ঘটতে পারে যদি:

  1. ক্লায়েন্ট অ্যাপ্লিকেশনে সেট করা টাইমআউট মান রাউটার এবং মেসেজ প্রসেসরে সেট করা টাইমআউট মান থেকে কম:

    উদাহরণস্বরূপ, যদি নিম্নলিখিত টাইমআউট মান সেট করা হয়:

    ক্লায়েন্টের উপর সময়সীমা রাউটারে টাইমআউট মেসেজ প্রসেসরে টাইমআউট
    50 সেকেন্ড 57 সেকেন্ড 55 সেকেন্ড

    এই ক্ষেত্রে, এজ এর মাধ্যমে একটি API অনুরোধের জন্য একটি প্রতিক্রিয়া পাওয়ার জন্য উপলব্ধ মোট সময় হল <= 50 সেকেন্ড। এর মধ্যে একটি API অনুরোধ করতে সময় নেওয়া, এজ (রাউটার, মেসেজ প্রসেসর) দ্বারা প্রক্রিয়াকৃত অনুরোধ, ব্যাকএন্ড সার্ভারে পাঠানো অনুরোধ (যদি প্রযোজ্য হয়), ব্যাকএন্ড অনুরোধ প্রক্রিয়াকরণ এবং প্রতিক্রিয়া পাঠানো, এজ প্রতিক্রিয়া প্রক্রিয়াকরণ এবং অবশেষে এটি ক্লায়েন্টের কাছে ফেরত পাঠাচ্ছে।

    যদি রাউটার 50 সেকেন্ডের মধ্যে ক্লায়েন্টকে সাড়া না দেয়, তাহলে ক্লায়েন্ট টাইমআউট করবে এবং রাউটারের সাথে সংযোগ বন্ধ করে দেবে। ক্লায়েন্ট 504 এর রেসপন্স কোড পাবেন।

    এর ফলে NGINX 499 এর একটি স্ট্যাটাস কোড সেট করবে যা নির্দেশ করে যে ক্লায়েন্ট সংযোগ বন্ধ করেছে।

রোগ নির্ণয়

  1. রাউটার থেকে সাড়া পাওয়ার আগেই ক্লায়েন্ট অ্যাপ্লিকেশনের সময় শেষ হলে, এটি রাউটারের সাথে সংযোগ বন্ধ করে দেবে। এই পরিস্থিতিতে, আপনি নির্দিষ্ট API অনুরোধের জন্য NGINX অ্যাক্সেস লগগুলিতে 499 এর একটি স্ট্যাটাস কোড দেখতে পাবেন।

    নমুনা NGINX লগ এন্ট্রি স্ট্যাটাস কোড 499 দেখাচ্ছে

  2. উপরের উদাহরণে, মনে রাখবেন যে NGINX-এ 499 এর স্থিতি এবং মোট সময় অতিবাহিত হয়েছে 50.001 সেকেন্ড। এটি নির্দেশ করে যে 50.001 সেকেন্ড পরে ক্লায়েন্টের সময় শেষ হয়েছে৷
  3. এই ক্ষেত্রে, আপনি মেসেজ প্রসেসর লগগুলিতে ( /opt/apigee/var/log/edge-message-processor/logs/system.log). Broken Pipe ব্যতিক্রম দেখতে পাবেন।
    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. যদি ব্যাকএন্ড সার্ভার ঠিক করা/অপ্টিমাইজ করা সম্ভব না হয় বা আপনি যদি জানেন যে ব্যাকএন্ড সার্ভারটি অনেক সময় নেবে, তাহলে রাউটার এবং মেসেজ প্রসেসরে টাইমআউট মান বাড়ান ।

      আইডিয়া: নিম্নলিখিত ক্রমে বিভিন্ন উপাদানের সময়সীমার মান সেট করুন:

      ক্লায়েন্টের সময়সীমা> রাউটারের সময়সীমা> বার্তা প্রসেসরের সময়সীমা> API প্রক্সির মধ্যে সময় শেষ

  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 এজ সাপোর্টের সাথে যোগাযোগ করুন এবং থ্রেড ডাম্প, হিপ ডাম্প এবং মেসেজ প্রসেসর লগ ( /opt/apigee/var/log/edge-message-processor/logs/system.log) প্রদান করুন যাতে তাদের উচ্চ CPU/ এর কারণ অনুসন্ধান করতে সহায়তা করে মেমরি ব্যবহার।

রাউটার এবং মেসেজ প্রসেসরে টাইমআউট মান বাড়ান

আপনার প্রয়োজনীয়তার উপর নির্ভর করে রাউটার এবং বার্তা প্রসেসরে সেট করা সময়সীমার মানগুলি সাবধানে চয়ন করুন। নির্বিচারে বড় টাইমআউট মান সেট করবেন না। আপনার যদি সহায়তার প্রয়োজন হয়, 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. আপনার যদি একাধিক বার্তা প্রসেসর থাকে তবে সমস্ত বার্তা প্রসেসরে উপরের পদক্ষেপগুলি পুনরাবৃত্তি করুন৷

আইডিয়া: নিম্নলিখিত ক্রমে বিভিন্ন উপাদানের সময়সীমার মান সেট করুন:

ক্লায়েন্টের সময়সীমা> রাউটারের সময়সীমা> বার্তা প্রসেসরের সময়সীমা> API প্রক্সির মধ্যে সময় শেষ

এজ দ্বারা ধীর API অনুরোধ প্রক্রিয়াকরণ

যদি এজ খুব ধীর হয় এবং/অথবা API অনুরোধ প্রক্রিয়া করতে দীর্ঘ সময় নেয়, তাহলে আপনি একটি 504 Gateway Timeout ত্রুটি পাবেন।

রোগ নির্ণয়

  1. এজ UI এ প্রভাবিত API ট্রেস করুন।
  2. হয় ত্রুটি হওয়ার জন্য অপেক্ষা করুন অথবা আপনার যদি API কল থাকে, তাহলে কিছু API কল করুন এবং 504 Gateway Timeout ত্রুটিটি পুনরুত্পাদন করুন।
  3. দ্রষ্টব্য, এই ক্ষেত্রে, আপনি ট্রেসে একটি সফল প্রতিক্রিয়া দেখতে পারেন৷
    1. মেসেজ প্রসেসর হিসাবে রাউটার/ক্লায়েন্ট টাইম আউট হয়ে যায় রাউটার/ক্লায়েন্টের নির্দিষ্ট সময়সীমার মধ্যে (যার মধ্যে সর্বনিম্ন সময় শেষ হয়)। যাইহোক, বার্তা প্রসেসর অনুরোধটি প্রক্রিয়া করতে থাকে এবং সফলভাবে সম্পন্ন হতে পারে।
    2. উপরন্তু, মেসেজ প্রসেসরে সেট করা HTTPTransport.io.timeout.millis মান শুধুমাত্র তখনই ট্রিগার হয় যখন মেসেজ প্রসেসর একটি HTTP/HTTPS ব্যাকএন্ড সার্ভারের সাথে যোগাযোগ করে। অন্য কথায়, API প্রক্সির মধ্যে কোনো নীতি (সার্ভিসকলআউট নীতি ব্যতীত) দীর্ঘ সময় নিলে এই সময়সীমা ট্রিগার হবে না।
  4. ত্রুটিটি হওয়ার পরে, নির্দিষ্ট অনুরোধটি পরীক্ষা করুন যার দীর্ঘতম সময় অতিবাহিত হয়েছে৷
  5. প্রতিটি পর্যায়ে অতিবাহিত সময় পরীক্ষা করুন এবং যে পর্যায়ে সবচেয়ে বেশি সময় ব্যয় হয় তার একটি নোট করুন।
  6. আপনি যদি পরিষেবা কলআউট নীতি ব্যতীত অন্য কোনও নীতিতে দীর্ঘতম অতিবাহিত সময় পর্যবেক্ষণ করেন, তাহলে এটি নির্দেশ করে যে এজ অনুরোধটি প্রক্রিয়া করতে দীর্ঘ সময় নিচ্ছে।
  7. এখানে একটি নমুনা UI ট্রেস যা জাভাস্ক্রিপ্ট নীতিতে অতি অতিবাহিত সময় দেখায়:

  8. উপরের উদাহরণে, আপনি লক্ষ্য করেছেন যে জাভাস্ক্রিপ্ট নীতি ~ 245 সেকেন্ডের একটি অস্বাভাবিকভাবে দীর্ঘ সময় নেয়।

রেজোলিউশন

  1. যে পলিসিটি সাড়া দিতে দীর্ঘ সময় নেয় এবং এমন কোনো কাস্টম কোড আছে যা প্রক্রিয়া করতে দীর্ঘ সময় লাগতে পারে তা পরীক্ষা করুন। যদি এমন কোন কোড থাকে, তাহলে দেখুন আপনি চিহ্নিত কোডটি ঠিক/অপ্টিমাইজ করতে পারেন কিনা।
  2. যদি এমন কোন কাস্টম কোড না থাকে যা উচ্চ প্রক্রিয়াকরণের সময় হতে পারে, তাহলে বার্তা প্রসেসরগুলি উচ্চ CPU বা মেমরি ব্যবহার করছে কিনা তা পরীক্ষা করুন:
    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 এজ সাপোর্টের সাথে যোগাযোগ করুন এবং থ্রেড ডাম্প, হিপ ডাম্প এবং মেসেজ প্রসেসর লগ ( /opt/apigee/var/log/edge-message-processor/logs/system.log) প্রদান করুন যাতে তাদের উচ্চ CPU/ এর কারণ অনুসন্ধান করতে সহায়তা করে মেমরি ব্যবহার।

API মনিটরিং ব্যবহার করে সমস্যা নির্ণয় করুন

API মনিটরিং আপনাকে ত্রুটি, কর্মক্ষমতা, এবং লেটেন্সি সমস্যা এবং তাদের উৎস যেমন ডেভেলপার অ্যাপস, API প্রক্সি, ব্যাকএন্ড টার্গেট বা API প্ল্যাটফর্ম নির্ণয় করতে সমস্যা এলাকাগুলিকে দ্রুত বিচ্ছিন্ন করতে সক্ষম করে।

এপিআই মনিটরিং ব্যবহার করে আপনার এপিআইগুলির সাথে 5xx সমস্যাগুলি কীভাবে সমাধান করা যায় তা প্রদর্শন করে এমন একটি নমুনা দৃশ্যের মধ্য দিয়ে যান । উদাহরণস্বরূপ, যখন 504 স্ট্যাটাস কোডের সংখ্যা একটি নির্দিষ্ট থ্রেশহোল্ড অতিক্রম করে তখন আপনি বিজ্ঞপ্তি পাওয়ার জন্য একটি সতর্কতা সেট আপ করতে চাইতে পারেন।