502 ভুল গেটওয়ে অপ্রত্যাশিত EOF

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

সমস্যার উপসর্গ

API কলের উত্তর হিসেবে ক্লায়েন্ট অ্যাপ্লিকেশন 502 HTTP স্ট্যাটাস কোড সহ এই মেসেজটি পায়: Bad Gateway

HTTP স্ট্যাটাস কোড 502-এর অর্থ হল, ক্লায়েন্ট ব্যাকএন্ড সার্ভার থেকে সঠিক উত্তর পাচ্ছে না যা আসলে অনুরোধটি সম্পূর্ণ করার কথা।

সমস্যার মেসেজ

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

HTTP/1.1 502 Bad Gateway

এছাড়াও, আপনি নিম্নলিখিত সমস্যার মেসেজ দেখতে পেতে পারেন:

{
   "fault": {
      "faultstring": "Unexpected EOF at target",
      "detail": {
           "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
       }
    }
}

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

502 Bad Gateway Error সমস্যার একটি সাধারণ কারণ হল Unexpected EOF সমস্যা, যা নিম্নলিখিত কারণে হতে পারে:

সাধারণ ডায়াগনসিস ধাপ

সমস্যা নির্ণয় করতে, আপনি নিম্নলিখিত যেকোনও পদ্ধতি ব্যবহার করতে পারেন:

• API মনিটরিং
• ট্রেস টুল
• NGINX অ্যাক্সেস লগ

কারণ: টার্গেট সার্ভার ভুলভাবে কনফিগার করা হয়েছে

TLS/SSL কানেকশন কাজ করার জন্য টার্গেট সার্ভার সঠিকভাবে কনফিগার করা হয়নি।

ডায়াগনসিস

1. 502 সমস্যার মেসেজ আইডি, ফল্ট কোড ও ফল্ট সোর্স নির্ধারণ করতে API মনিটরিং, ট্রেস টুল অথবা NGINX অ্যাক্সেস লগ ব্যবহার করুন।
2. প্রভাবিত API-এর জন্য UI-তে ট্রেস চালু করুন।
3. API অনুরোধ ব্যর্থ হওয়ার ট্রেসে যদি নিম্নলিখিত বিষয়গুলি দেখা যায়:
   1. টার্গেট ফ্লোয়ের অনুরোধ শুরু হওয়ার সাথে সাথেই 502 Bad Gateway সমস্যাটি দেখা যায়।
   2. error.class-এ messaging.adaptors.http.UnexpectedEOF. দেখানো হয়

      তাহলে, খুব সম্ভবত ভুল টার্গেট সার্ভার কনফিগারেশনের কারণে এই সমস্যা হয়েছে।

4. Edge ম্যানেজমেন্ট API কল ব্যবহার করে টার্গেট সার্ভারের সংজ্ঞা পান:
   1. আপনি পাবলিক ক্লাউড ব্যবহারকারী হলে, এই API ব্যবহার করুন:

      curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

   2. আপনি প্রাইভেট ক্লাউড ব্যবহারকারী হলে, এই API ব্যবহার করুন:

      curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

      TargetServer সংজ্ঞার নমুনা সংক্রান্ত ত্রুটি:

      <TargetServer  name="target1">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer >

5. ইলাস্ট্রেশন করা TargetServer সংজ্ঞাটি একটি সাধারণ ভুল কনফিগারেশনের উদাহরণ যা নিচে ব্যাখ্যা করা হল:

   ধরে নেওয়া যাক যে টার্গেট সার্ভার mocktarget.apigee.net, পোর্ট 443-এ সুরক্ষিত (HTTPS) কানেকশন গ্রহণ করার জন্য কনফিগার করা হয়েছে। তবে, আপনি যদি টার্গেট সার্ভারের সংজ্ঞা দেখেন, তাহলে এমন কোনও অ্যাট্রিবিউট/ফ্ল্যাগ নেই যা নির্দেশ করে যে এটি সুরক্ষিত কানেকশনের জন্য তৈরি করা হয়েছে। এর ফলে Edge, নির্দিষ্ট টার্গেট সার্ভারে যাওয়া API অনুরোধকে HTTP (সুরক্ষিত নয়) অনুরোধ হিসেবে বিবেচনা করে। তাই Edge এই টার্গেট সার্ভারের সাথে SSL হ্যান্ডশেক প্রসেস শুরু করবে না।

   যেহেতু টার্গেট সার্ভার 443-এ শুধুমাত্র HTTPS (SSL) অনুরোধ গ্রহণ করার জন্য কনফিগার করা আছে, তাই এটি Edge থেকে আসা অনুরোধ প্রত্যাখ্যান করবে বা কানেকশন বন্ধ করে দেবে। এর ফলে, আপনি মেসেজ প্রসেসরে UnexpectedEOFAtTarget সমস্যা দেখতে পাবেন। মেসেজ প্রসেসর ক্লায়েন্টকে উত্তর হিসেবে 502 Bad Gateway পাঠাবে।

রেজোলিউশন

আপনার প্রয়োজন অনুযায়ী টার্গেট সার্ভার সঠিকভাবে কনফিগার করা হয়েছে কিনা তা সবসময় নিশ্চিত করুন।

উপরের উদাহরণে দেখানো ছবিটির জন্য, আপনি যদি কোনও সুরক্ষিত (HTTPS/SSL) টার্গেট সার্ভারে অনুরোধ করতে চান, তাহলে আপনাকে enabled ফ্ল্যাগ সেট করা SSLInfo অ্যাট্রিবিউট true-এ অন্তর্ভুক্ত করতে হবে। টার্গেট এন্ডপয়েন্ট ডেফিনিশনে টার্গেট সার্ভারের জন্য SSLInfo অ্যাট্রিবিউট যোগ করার অনুমতি থাকলেও, কোনও বিভ্রান্তি এড়াতে টার্গেট সার্ভার ডেফিনিশনের অংশ হিসেবে SSLInfo অ্যাট্রিবিউট যোগ করার পরামর্শ দেওয়া হয়।

1. ব্যাকএন্ড পরিষেবার একমুখী SSL কমিউনিকেশন প্রয়োজন হলে, তাহলে:
   1. আপনাকে TargetServer ডেফিনিশনে TLS/SSL চালু করতে হবে, এর জন্য SSLInfo অ্যাট্রিবিউট যোগ করতে হবে যেখানে enabled ফ্ল্যাগকে নিচে দেখানো মতো true হিসেবে সেট করা হয়েছে:

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>

   2. আপনি Edge-এ টার্গেট সার্ভারের সার্টিফিকেট যাচাই করতে চাইলে, আমাদেরও নিচে দেখানো উপায়ে ট্রাস্টস্টোর (যেখানে টার্গেট সার্ভারের সার্টিফিকেট আছে) অন্তর্ভুক্ত করতে হবে:

      <TargetServer  name="mocktarget">
          <Host>mocktarget.apigee.net</Host>
          <Port>443</Port>
          <IsEnabled>true</IsEnabled>
          <SSLInfo>
              <Ciphers/>
              <ClientAuthEnabled>false</ClientAuthEnabled>
              <Enabled>true</Enabled>
              <IgnoreValidationErrors>false</IgnoreValidationErrors>
              <Protocols/>
              <TrustStore>mocktarget-truststore</TrustStore>
          </SSLInfo>
      </TargetServer>

2. ব্যাকএন্ড পরিষেবার টু-ওয়ে SSL কমিউনিকেশন প্রয়োজন হলে, তাহলে:
   1. নিচে দেখানো অনুযায়ী, আপনাকে ClientAuthEnabled, Keystore, KeyAlias এবং Truststore ফ্ল্যাগ সঠিকভাবে সেট করা SSLInfo অ্যাট্রিবিউট রাখতে হবে:

      <TargetServer  name="mocktarget">
           <IsEnabled>true</IsEnabled>
           <Host>www.example.com</Host>
           <Port>443</Port>
           <SSLInfo>
               <Ciphers/>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <Enabled>true</Enabled>
               <IgnoreValidationErrors>false</IgnoreValidationErrors>
               <KeyAlias>keystore-alias</KeyAlias>
               <KeyStore>keystore-name</KeyStore>
               <Protocols/>
               <TrustStore>truststore-name</TrustStore>
           </SSLInfo>
        </TargetServer >

রেফারেন্স

ব্যাকএন্ড সার্ভার জুড়ে লোড ব্যালেন্সিং

কারণ: ব্যাকএন্ড সার্ভার থেকে EOFException

ব্যাকএন্ড সার্ভার হঠাৎ করে EOF (ফাইলের শেষ) পাঠাতে পারে।

ডায়াগনসিস

1. 502 সমস্যার মেসেজ আইডি, ফল্ট কোড ও ফল্ট সোর্স নির্ধারণ করতে API মনিটরিং, ট্রেস টুল অথবা NGINX অ্যাক্সেস লগ ব্যবহার করুন।
2. Message Processor লগ চেক করুন (/opt/apigee/var/log/edge-message-processor/logs/system.log) এবং নির্দিষ্ট API-এর জন্য আপনার কাছে eof unexpected আছে কিনা অথবা API অনুরোধের জন্য আপনার কাছে অনন্য messageid আছে কিনা তা দেখুন, তাহলে আপনি এটি সার্চ করতে পারবেন।

   মেসেজ প্রসেসর লগ থেকে ব্যতিক্রমী স্ট্যাক ট্রেসের নমুনা

   "message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {}
   java.io.EOFException: eof unexpected
   at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na]
   at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na]
   at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na]
   at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na]
   at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"

   উপরের উদাহরণে, আপনি দেখতে পাবেন যে মেসেজ প্রসেসর যখন ব্যাকএন্ড সার্ভার থেকে উত্তর পড়ার চেষ্টা করছে, তখন java.io.EOFException: eof unexpected সমস্যা হয়েছে। এই ব্যতিক্রমটি ফাইলের শেষ (EOF) বা স্ট্রিমের শেষকে নির্দেশ করে যা অপ্রত্যাশিতভাবে পৌঁছে গেছে।

   অর্থাৎ, মেসেজ প্রসেসর ব্যাকএন্ড সার্ভারে API অনুরোধ পাঠিয়েছে এবং উত্তর পাওয়ার জন্য অপেক্ষা করছে অথবা উত্তর পড়ছে। তবে, মেসেজ প্রসেসর উত্তর পাওয়ার বা সম্পূর্ণ উত্তর পড়ার আগেই ব্যাকএন্ড সার্ভার হঠাৎ করে কানেকশন বন্ধ করে দেয়।

3. আপনার ব্যাকএন্ড সার্ভার লগ চেক করে দেখুন যে কোনও সমস্যা বা তথ্য আছে কিনা যা ব্যাকএন্ড সার্ভারকে হঠাৎ করে কানেকশন বন্ধ করে দিতে বাধ্য করেছে। আপনি কোনও সমস্যা/তথ্য খুঁজে পেলে, সমাধান বিভাগে যান এবং আপনার ব্যাকএন্ড সার্ভারে সমস্যাটি যথাযথভাবে সমাধান করুন।
4. আপনার ব্যাকএন্ড সার্ভারে কোনও সমস্যা বা তথ্য খুঁজে না পেলে, মেসেজ প্রসেসরের tcpdump আউটপুট সংগ্রহ করুন:
   1. আপনার ব্যাকএন্ড সার্ভার হোস্টের একটি IP অ্যাড্রেস থাকলে, নিম্নলিখিত কমান্ড ব্যবহার করুন:

      tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME

   2. আপনার ব্যাকএন্ড সার্ভার হোস্টের একাধিক IP অ্যাড্রেস থাকলে, নিম্নলিখিত কমান্ড ব্যবহার করুন:

      tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME

      মেসেজ প্রসেসরের IP অ্যাড্রেস ব্যবহার করুন।

      সাধারণত, এই সমস্যাটি ঘটে কারণ মেসেজ প্রসেসর ব্যাকএন্ড সার্ভারে অনুরোধ পাঠানোর সাথে সাথেই ব্যাকএন্ড সার্ভার [FIN,ACK] দিয়ে উত্তর দেয়।

5. নিচের tcpdump উদাহরণটি দেখুন।

   502 Bad Gateway Error (UnexpectedEOFAtTarget) হলে tcpdump স্যাম্পেল নেওয়া হয়েছে

   

6. TCPDump আউটপুট থেকে, আপনি ইভেন্টের নিম্নলিখিত ক্রম লক্ষ্য করেছেন:
   1. প্যাকেট 985-এ, মেসেজ প্রসেসর ব্যাকএন্ড সার্ভারে API অনুরোধ পাঠায়।
   2. প্যাকেট 986-এ, ব্যাকএন্ড সার্ভার সঙ্গে সঙ্গে [FIN,ACK] দিয়ে উত্তর দেয়।
   3. প্যাকেট 987-এ, মেসেজ প্রসেসর ব্যাকএন্ড সার্ভারকে [FIN,ACK] দিয়ে উত্তর দেয়।
   4. অবশেষে, [ACK] এবং [RST]-এর মাধ্যমে দুই দিক থেকেই কানেকশন বন্ধ হয়ে যায়।
   5. যেহেতু ব্যাকএন্ড সার্ভার [FIN,ACK] পাঠায়, তাই আপনি Message Processor-এ ব্যতিক্রম java.io.EOFException: eof unexpected ব্যতিক্রম পান।
7. ব্যাকএন্ড সার্ভারে নেটওয়ার্ক সংক্রান্ত সমস্যা হলে এটি হতে পারে। এই সমস্যা আরও খতিয়ে দেখতে আপনার নেটওয়ার্ক অপারেশন টিমকে কাজে লাগান।

রেজোলিউশন

ব্যাকএন্ড সার্ভারে যথাযথভাবে সমস্যার সমাধান করুন।

সমস্যাটি থেকে গেলে এবং 502 Bad Gateway Error-এর সমস্যা সমাধানের জন্য আপনার সাহায্যের প্রয়োজন হলে অথবা আপনি যদি মনে করেন যে এটি Edge-এর মধ্যে কোনও সমস্যা, তাহলে Apigee Edge সহায়তা টিমের সাথে যোগাযোগ করুন।

কারণ: ভুলভাবে কনফিগার করা 'কিপ অ্যালাইভ' টাইমআউট

502 সমস্যার কারণ এটি কিনা তা ডায়াগনসিস করার আগে, নিম্নলিখিত বিষয়গুলি পড়ে দেখুন।

Apigee-তে পারসিস্ট্যান্ট কানেকশন

টার্গেট ব্যাকএন্ড সার্ভারের সাথে যোগাযোগ করার সময় Apigee ডিফল্ট হিসেবে (এবং HTTP/1.1 স্ট্যান্ডার্ড মেনে) পারসিস্টেন্ট কানেকশন ব্যবহার করে। আগে থেকেই প্রতিষ্ঠিত TCP এবং (প্রযোজ্য হলে) TLS/SSL কানেকশন আবার ব্যবহার করার অনুমতি দিয়ে, পারসিস্টেন্ট কানেকশন পারফর্ম্যান্স বাড়াতে পারে। এর ফলে লেটেন্সি ওভারহেড কমে যায়। কানেকশন কতক্ষণ ধরে বজায় রাখতে হবে তা একটি প্রপার্টির মাধ্যমে কন্ট্রোল করা হয় কিপ অ্যালাইভ টাইমআউট (keepalive.timeout.millis)।

ব্যাকএন্ড সার্ভার ও Apigee মেসেজ প্রসেসর, একে অপরের সাথে কানেকশন চালু রাখতে কিপ-অ্যালাইভ টাইমআউট ব্যবহার করে। কিপ অ্যালাইভ টাইমআউট সময়ের মধ্যে কোনও ডেটা না পেলে, ব্যাকএন্ড সার্ভার বা মেসেজ প্রসেসর একে অপরের সাথে কানেকশন বন্ধ করে দিতে পারে।

Apigee-তে মেসেজ প্রসেসরে ডিফল্ট হিসেবে ডিপ্লয় করা API প্রক্সিতে, 60sওভাররাইড না করা পর্যন্ত, কিপ-অ্যালাইভ টাইমআউট সেট করা থাকে। 60s-এর জন্য কোনও ডেটা না পেলে, Apigee ব্যাকএন্ড সার্ভারের সাথে কানেকশন বন্ধ করে দেবে। এছাড়াও, ব্যাকএন্ড সার্ভার একটি কিপ-অ্যালাইভ টাইমআউট বজায় রাখবে, এবং এটি শেষ হয়ে গেলে, ব্যাকএন্ড সার্ভার মেসেজ প্রসেসরের সাথে কানেকশন বন্ধ করে দেবে।

সঠিক নয় এমন 'কিপ অ্যালাইভ' টাইমআউট কনফিগারেশনের প্রভাব

Apigee বা ব্যাকএন্ড সার্ভার, কোনওটিতেই যদি ভুল 'কিপ-অ্যালাইভ' টাইমআউট কনফিগার করা থাকে, তাহলে এর ফলে রেস কন্ডিশন তৈরি হয় এবং এর ফলে ব্যাকএন্ড সার্ভার কোনও রিসোর্সের অনুরোধের উত্তরে অপ্রত্যাশিত End Of File (FIN) পাঠায়।

যেমন, API প্রক্সি বা মেসেজ প্রসেসরের মধ্যে যদি কিপ-অ্যালাইভ টাইমআউট কনফিগার করা থাকে এবং তার ভ্যালু যদি আপস্ট্রিম ব্যাকএন্ড সার্ভারের টাইমআউটের সমান বা তার থেকে বেশি হয়, তাহলে নিম্নলিখিত রেস কন্ডিশন হতে পারে। অর্থাৎ, ব্যাকএন্ড সার্ভারের কিপ-অ্যালাইভ টাইমআউটের থ্রেশহোল্ডের খুব কাছাকাছি সময় পর্যন্ত মেসেজ প্রসেসর কোনও ডেটা না পেলে, একটি অনুরোধ আসে এবং আগে থেকে থাকা কানেকশন ব্যবহার করে ব্যাকএন্ড সার্ভারে পাঠানো হয়। এর ফলে 502 Bad Gateway হতে পারে, নিচে এর কারণ ব্যাখ্যা করা হল:

1. ধরা যাক, মেসেজ প্রসেসর ও ব্যাকএন্ড সার্ভার দু'টিতেই 'কিপ অ্যালাইভ' টাইমআউট ৬০ সেকেন্ড হিসেবে সেট করা আছে এবং নির্দিষ্ট মেসেজ প্রসেসর আগের অনুরোধটি প্রসেস করার পরে ৫৯ সেকেন্ড পর্যন্ত কোনও নতুন অনুরোধ আসেনি।
2. মেসেজ প্রসেসর এগিয়ে যায় এবং ৫৯ সেকেন্ডে আসা অনুরোধটি প্রসেস করে আগেকার কানেকশন ব্যবহার করে (কারণ কিপ অ্যালাইভ টাইমআউট এখনও শেষ হয়নি) এবং ব্যাকএন্ড সার্ভারে অনুরোধ পাঠায়।
3. তবে, অনুরোধটি ব্যাকএন্ড সার্ভারে পৌঁছানোর আগেই ব্যাকএন্ড সার্ভারে কিপ-অ্যালাইভ টাইমআউট থ্রেশহোল্ড অতিক্রম করে গেছে।
4. মেসেজ প্রসেসরের রিসোর্সের অনুরোধ ইন-ফ্লাইট আছে, কিন্তু ব্যাকএন্ড সার্ভার মেসেজ প্রসেসরকে FIN প্যাকেট পাঠিয়ে কানেকশন বন্ধ করার চেষ্টা করে।
5. মেসেজ প্রসেসর ডেটা পাওয়ার জন্য অপেক্ষা করার সময়, পরিবর্তে অপ্রত্যাশিত FIN পায় এবং কানেকশন বন্ধ হয়ে যায়।
6. এর ফলে Unexpected EOF এবং তারপরে মেসেজ প্রসেসর ক্লায়েন্টকে 502 রিটার্ন করে।

এই ক্ষেত্রে, আমরা লক্ষ্য করেছি যে 502 সমস্যাটি হয়েছে কারণ মেসেজ প্রসেসর এবং ব্যাকএন্ড সার্ভার, দু'টিতেই একই কিপ অ্যালাইভ টাইমআউট ভ্যালু ৬০ সেকেন্ড কনফিগার করা ছিল। একইভাবে, মেসেজ প্রসেসরের জন্য ব্যাকএন্ড সার্ভারের তুলনায় বেশি ভ্যালু কনফিগার করা থাকলে, এই সমস্যা হতে পারে।

ডায়াগনসিস

1. আপনি পাবলিক ক্লাউড ব্যবহারকারী হলে:
   1. API মনিটরিং বা ট্রেস টুল ব্যবহার করুন (যেমন সাধারণ ডায়াগনসিস ধাপ-এ ব্যাখ্যা করা হয়েছে) এবং যাচাই করুন যে আপনার কাছে নিম্নলিখিত দুটি সেটিংসই আছে:
      • সমস্যার কোড: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • সমস্যার সোর্স: target
   2. আরও তদন্ত করতে tcpdump ব্যবহার করা লিঙ্কে যান।
2. আপনি প্রাইভেট ক্লাউড ব্যবহারকারী হলে:
   1. 502 সমস্যার জন্য মেসেজ আইডি, ফল্ট কোড এবং ফল্ট সোর্স নির্ধারণ করতে ট্রেস টুল বা NGINX অ্যাক্সেস লগ ব্যবহার করুন।
   2. Message Processor log-এ মেসেজ আইডি সার্চ করুন
      (/opt/apigee/var/log/edge-message-processor/logs/system.log)।
   3. আপনি নিচে দেখানো java.io.EOFEXception: eof unexpected দেখতে পাবেন:

      2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1  NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() :  ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms  lastIO=479ms  isOpen=true.onExceptionRead exception: {}
              java.io.EOFException: eof unexpected
              at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45)
              at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103)
              at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80)
              at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51)
              at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)

   4. সমস্যা java.io.EOFException: eof unexpected থেকে বোঝা যায় যে মেসেজ প্রসেসর একটি EOF পেয়েছে, যখন এটি ব্যাকএন্ড সার্ভার থেকে উত্তর পাওয়ার জন্য অপেক্ষা করছিল।
   5. উপরের সমস্যা সংক্রান্ত মেসেজে useCount=7 অ্যাট্রিবিউট থেকে বোঝা যায় যে মেসেজ প্রসেসর এই কানেকশনটি প্রায় সাতবার আবার ব্যবহার করেছে এবং bytesWritten=159 অ্যাট্রিবিউট থেকে বোঝা যায় যে মেসেজ প্রসেসর ব্যাকএন্ড সার্ভারে 159 বাইটের অনুরোধ পেলোড পাঠিয়েছে। তবে, অপ্রত্যাশিত EOF হওয়ার সময় এটি শূন্য বাইট পেয়েছে।

   6. এটি থেকে বোঝা যায় যে মেসেজ প্রসেসর একই কানেকশন একাধিকবার ব্যবহার করেছে, এবং এই ক্ষেত্রে এটি ডেটা পাঠিয়েছে, কিন্তু কিছুক্ষণ পরেই কোনও ডেটা পাওয়ার আগে একটি EOF পায়। এর অর্থ হল, ব্যাকএন্ড সার্ভারের কিপ-অ্যালাইভ টাইমআউট API প্রক্সিতে সেট করা টাইমআউটের সমান বা তার থেকে কম হওয়ার সম্ভাবনা বেশি।

      নিচে যেভাবে ব্যাখ্যা করা হয়েছে, সেই অনুযায়ী tcpdump-এর সাহায্যে আপনি আরও তদন্ত করতে পারবেন।

tcpdump ব্যবহার করা

1. নিম্নলিখিত কমান্ডের সাহায্যে ব্যাকএন্ড সার্ভারে tcpdump ক্যাপচার করুন:

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name

2. tcpdump ক্যাপচার করা বিশ্লেষণ করুন:

   tcpdump আউটপুটের নমুনা এখানে দেওয়া হল:

   

   উপরের নমুনা tcpdump-এ, আপনি নিম্নলিখিত বিষয়গুলি দেখতে পাবেন:

   1. প্যাকেট 5992,-এ ব্যাকএন্ড সার্ভার একটি GET অনুরোধ পেয়েছে।
   2. প্যাকেট 6064-এ, এটি 200 OK. দিয়ে উত্তর দেয়
   3. প্যাকেট 6084-এ, ব্যাকএন্ড সার্ভার আরেকটি GET অনুরোধ পেয়েছে।
   4. প্যাকেট 6154-এ, এটি 200 OK দিয়ে উত্তর দেয়।
   5. প্যাকেট 6228-এ, ব্যাকএন্ড সার্ভার একটি থার্ড GET অনুরোধ পেয়েছে।
   6. এইবার, ব্যাকএন্ড সার্ভার মেসেজ প্রসেসরকে FIN, ACK রিটার্ন করে (প্যাকেট 6285) যা কানেকশন বন্ধ করার প্রসেস শুরু করে।

   এই উদাহরণে একই কানেকশন দু'বার সফলভাবে আবার ব্যবহার করা হয়েছে, কিন্তু তৃতীয় অনুরোধে, ব্যাকএন্ড সার্ভার কানেকশন বন্ধ করার প্রসেস শুরু করে, যেখানে মেসেজ প্রসেসর ব্যাকএন্ড সার্ভার থেকে ডেটা পাওয়ার জন্য অপেক্ষা করছে। এর থেকে বোঝা যায় যে ব্যাকএন্ড সার্ভারের কিপ অ্যালাইভ টাইমআউট সম্ভবত API প্রক্সিতে সেট করা ভ্যালুর সমান বা তার থেকে কম। এটি যাচাই করতে, Apigee ও ব্যাকএন্ড সার্ভারে 'কিপ-অ্যালাইভ' টাইমআউট তুলনা করুন দেখুন।

Apigee এবং ব্যাকএন্ড সার্ভারে 'কিপ অ্যালাইভ' টাইমআউটের তুলনা করা

1. ডিফল্ট হিসেবে, Apigee, 'কিপ অ্যালাইভ' টাইমআউট প্রপার্টির জন্য ৬০ সেকেন্ডের ভ্যালু ব্যবহার করে।

2. তবে, এটি সম্ভব যে আপনি API প্রক্সিতে ডিফল্ট মান ওভাররাইড করেছেন। 502 সমস্যা দেখাচ্ছে এমন API প্রক্সি ফেল করার নির্দিষ্ট TargetEndpoint সংজ্ঞা চেক করে আপনি এটি যাচাই করতে পারবেন।

   TargetEndpoint কনফিগারেশনের নমুনা:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="keepalive.timeout.millis">30000</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>

   উপরের উদাহরণে, ৩০ সেকেন্ড (30000 মিলিসেকেন্ড) ভ্যালু দিয়ে 'কিপ অ্যালাইভ টাইমআউট' প্রপার্টি ওভাররাইড করা হয়েছে।

3. এরপরে, আপনার ব্যাকএন্ড সার্ভারে কনফিগার করা 'কিপ অ্যালাইভ' টাইমআউট প্রপার্টি চেক করুন। ধরা যাক, আপনার ব্যাকএন্ড সার্ভার 25 seconds ভ্যালু দিয়ে কনফিগার করা আছে।
4. আপনি যদি নির্ধারণ করেন যে Apigee-তে কিপ-অ্যালাইভ টাইমআউট প্রপার্টির ভ্যালু উপরের উদাহরণে দেখানো ব্যাকএন্ড সার্ভারে কিপ-অ্যালাইভ টাইমআউট প্রপার্টির ভ্যালুর চেয়ে বেশি, তাহলে 502 সমস্যার কারণ এটিই।

রেজোলিউশন

ব্যাকএন্ড সার্ভারের তুলনায় Apigee-তে (API প্রক্সি এবং মেসেজ প্রসেসর কম্পোনেন্ট) 'কিপ অ্যালাইভ টাইমআউট' প্রপার্টির মান সবসময় কম থাকে কিনা তা নিশ্চিত করুন।

1. ব্যাকএন্ড সার্ভারে 'কিপ অ্যালাইভ' টাইমআউটের জন্য সেট করা ভ্যালু নির্ধারণ করুন।
2. API প্রক্সি বা মেসেজ প্রসেসরে কিপ অ্যালাইভ টাইমআউট প্রপার্টির জন্য উপযুক্ত ভ্যালু কনফিগার করুন, যাতে কিপ অ্যালাইভ টাইমআউট প্রপার্টির ভ্যালু ব্যাকএন্ড সার্ভারে সেট করা ভ্যালুর থেকে কম হয়। এটি করার জন্য মেসেজ প্রসেসরে কিপ অ্যালাইভ টাইমআউট কনফিগার করা লিঙ্কে গিয়ে ধাপে ধাপে নির্দেশাবলী অনুসরণ করুন।

এর পরেও সমস্যা থেকে গেলে, রোগ নির্ণয় সংক্রান্ত তথ্য অবশ্যই সংগ্রহ করতে হবে লিঙ্কে যান।

পেশাদার পদ্ধতি

এই ধরনের রেস কন্ডিশন ও 502 সমস্যা এড়াতে, ডাউনস্ট্রিম কম্পোনেন্টগুলিতে আপস্ট্রিম সার্ভারের তুলনায় সবসময় কম কিপ অ্যালাইভ টাইমআউট থ্রেশহোল্ড কনফিগার করার জন্য জোরদার পরামর্শ দেওয়া হয়। প্রতিটি ডাউনস্ট্রিম হপ, প্রতিটি আপস্ট্রিম হপের থেকে কম হতে হবে। Apigee Edge-এ, নিম্নলিখিত নির্দেশিকা ব্যবহার করা ভাল:

1. ক্লায়েন্ট কিপ-অ্যালাইভ টাইমআউট, এজ রাউটার কিপ-অ্যালাইভ টাইমআউটের থেকে কম হতে হবে।
2. Edge রাউটারের কিপ-অ্যালাইভ টাইমআউট, মেসেজ প্রসেসরের কিপ-অ্যালাইভ টাইমআউটের থেকে কম হতে হবে।
3. মেসেজ প্রসেসর কিপ-অ্যালাইভ টাইমআউটকে টার্গেট সার্ভার কিপ-অ্যালাইভ টাইমআউটের থেকে কম হতে হবে।
4. Apigee-এর আগে বা পরে অন্য কোনও হপ থাকলে, একই নিয়ম প্রযোজ্য হবে। আপস্ট্রিমের সাথে কানেকশন বন্ধ করার দায়িত্ব সবসময় ডাউনস্ট্রিম ক্লায়েন্টের উপর ছেড়ে দেওয়া উচিত।

অবশ্যই ডায়াগনস্টিক তথ্য সংগ্রহ করতে হবে

উপরে উল্লেখ করা নির্দেশাবলী অনুসরণ করার পরেও সমস্যাটি থেকে গেলে, নিম্নলিখিত ডায়াগনস্টিক তথ্য সংগ্রহ করুন এবং তারপরে Apigee Edge সহায়তা টিমের সাথে যোগাযোগ করুন।

আপনি পাবলিক ক্লাউড ব্যবহারকারী হলে, নিম্নলিখিত তথ্য প্রদান করুন:

• সংস্থার নাম
• পরিবেশের নাম
• API প্রক্সির নাম
• 502 সমস্যাটি আবার তৈরি করতে curl কমান্ডটি সম্পূর্ণ করুন
• 502 Bad Gateway - Unexpected EOF সমস্যা সহ অনুরোধ থাকা ট্রেস ফাইল
• 502 সমস্যা বর্তমানে না হয়ে থাকলে, 502 সমস্যা আগে যখন হয়েছিল তখনকার সময়সীমা ও টাইমজোন সংক্রান্ত তথ্য দিন।

আপনি প্রাইভেট ক্লাউড ব্যবহারকারী হলে, নিম্নলিখিত তথ্য দিন:

• অনুরোধ সম্পূর্ণ না হওয়ার ক্ষেত্রে দেখা সম্পূর্ণ সমস্যার মেসেজ
• আপনি যে সংস্থার জন্য 502 সমস্যা লক্ষ্য করছেন তার নাম, এনভায়রনমেন্টের নাম ও API প্রক্সি নাম
• API Proxy বান্ডেল
• 502 Bad Gateway - Unexpected EOF সমস্যা সহ অনুরোধ থাকা ট্রেস ফাইল
• NGINX অ্যাক্সেস লগ
  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
• মেসেজ প্রসেসর লগ
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• 502 সমস্যা হওয়ার সময়সীমা ও টাইমজোন সংক্রান্ত তথ্য
• Tcpdumps মেসেজ প্রসেসর বা ব্যাকএন্ড সার্ভার অথবা দু'টিতেই সংগ্রহ করা হয়, যখন সমস্যা হয়েছিল