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

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

উপসর্গ

ক্লায়েন্ট অ্যাপ্লিকেশনটি API কলগুলির প্রতিক্রিয়া হিসাবে Bad Gateway বার্তা সহ 502 এর একটি 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. এজ ম্যানেজমেন্ট 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) সংযোগ গ্রহণ করার জন্য কনফিগার করা হয়েছে। যাইহোক, যদি আপনি টার্গেট সার্ভারের সংজ্ঞা দেখেন, অন্য কোন বৈশিষ্ট্য/পতাকা নেই যা নির্দেশ করে যে এটি সুরক্ষিত সংযোগের জন্য। এটি এজকে নির্দিষ্ট টার্গেট সার্ভারে যাওয়া API অনুরোধগুলিকে HTTP (অ-সুরক্ষিত) অনুরোধ হিসাবে বিবেচনা করে। তাই এজ এই টার্গেট সার্ভারের সাথে SSL হ্যান্ডশেক প্রক্রিয়া শুরু করবে না।

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

রেজোলিউশন

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

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

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

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

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

      <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. মেসেজ প্রসেসরের লগগুলি ( /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) নির্দেশ করে, বা স্ট্রিমের শেষ অপ্রত্যাশিতভাবে পৌঁছে গেছে।

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

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

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

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

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

      সাধারণত, এই ত্রুটিটি ঘটে কারণ বার্তা প্রসেসর ব্যাকএন্ড সার্ভারে অনুরোধ পাঠানোর সাথে সাথে ব্যাকএন্ড সার্ভার [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] পাঠায়, আপনি java.io.EOFException: eof unexpected ব্যতিক্রম পাবেন।
7. ব্যাকএন্ড সার্ভারে নেটওয়ার্ক সমস্যা হলে এটি ঘটতে পারে। এই সমস্যাটি আরও তদন্ত করতে আপনার নেটওয়ার্ক অপারেশন টিমকে নিযুক্ত করুন৷

রেজোলিউশন

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

যদি সমস্যাটি অব্যাহত থাকে এবং আপনার 502 Bad Gateway Error সমস্যা সমাধানে সহায়তার প্রয়োজন হয় বা আপনি সন্দেহ করেন যে এটি এজের মধ্যে একটি সমস্যা, 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 প্রক্সি বা মেসেজ প্রসেসরের মধ্যে Keep alive টাইমআউট কনফিগার করা হয়, তাহলে নিম্নলিখিত রেস অবস্থা ঘটতে পারে। অর্থাৎ, যদি বার্তা প্রসেসর ব্যাকএন্ড সার্ভারের থ্রেশহোল্ডের খুব কাছাকাছি না আসা পর্যন্ত কোনো ডেটা না পায়, তাহলে একটি অনুরোধ আসে এবং বিদ্যমান সংযোগ ব্যবহার করে ব্যাকএন্ড সার্ভারে পাঠানো হয়। নীচে ব্যাখ্যা করা অপ্রত্যাশিত EOF ত্রুটির কারণে এটি 502 Bad Gateway হতে পারে:

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

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

রোগ নির্ণয়

1. আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন:
   1. API মনিটরিং বা ট্রেস টুল ব্যবহার করুন ( সাধারণ নির্ণয়ের ধাপে ব্যাখ্যা করা হয়েছে) এবং যাচাই করুন যে আপনার কাছে নিম্নলিখিত উভয় সেটিংস রয়েছে:
      • ফল্ট কোড: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • ফল্ট উত্স: target
   2. আরও তদন্তের জন্য tcpdump ব্যবহারে যান।
2. আপনি যদি ব্যক্তিগত ক্লাউড ব্যবহারকারী হন:
   1. 502 ত্রুটির জন্য বার্তা আইডি, ফল্ট কোড এবং ফল্ট উৎস নির্ধারণ করতে ট্রেস টুল বা NGINX অ্যাক্সেস লগ ব্যবহার করুন।
   2. মেসেজ প্রসেসর লগে মেসেজ আইডি খুঁজুন
      ( /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 পেয়েছে। এর মানে হল যে ব্যাকএন্ড সার্ভারের কিপ অ্যালাইভ টাইমআউট এপিআই প্রক্সিতে সেটের তুলনায় ছোট বা সমান হওয়ার সম্ভাবনা রয়েছে।

      আপনি নীচে ব্যাখ্যা অনুযায়ী 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 লাইভ টাইমআউট বৈশিষ্ট্যের জন্য 60 সেকেন্ডের মান ব্যবহার করে।

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

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

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

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

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

রেজোলিউশন

ব্যাকএন্ড সার্ভারের তুলনায় অ্যাপিজিতে (এপিআই প্রক্সি এবং মেসেজ প্রসেসর উপাদানে) জীবিত টাইমআউট বৈশিষ্ট্য সবসময় কম থাকে তা নিশ্চিত করুন।

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

যদি সমস্যা এখনও থেকে যায়, তাহলে ডায়াগনস্টিক তথ্য সংগ্রহ করতে হবে ।

সর্বোত্তম অনুশীলন

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

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

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

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

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

• প্রতিষ্ঠানের নাম
• পরিবেশের নাম
• API প্রক্সি নাম
• 502 ত্রুটি পুনরুত্পাদন করতে curl কমান্ডটি সম্পূর্ণ করুন
• 502 Bad Gateway - Unexpected EOF ত্রুটি৷
• যদি 502 ত্রুটি বর্তমানে ঘটছে না, অতীতে যখন 502 ত্রুটি ঘটেছে সময় অঞ্চলের তথ্য সহ সময়কাল প্রদান করুন।

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

• ব্যর্থ অনুরোধের জন্য পরিলক্ষিত সম্পূর্ণ ত্রুটি বার্তা
• প্রতিষ্ঠান, পরিবেশের নাম এবং API প্রক্সি নাম যার জন্য আপনি 502 ত্রুটি পর্যবেক্ষণ করছেন
• API প্রক্সি বান্ডেল
• 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 মেসেজ প্রসেসর বা ব্যাকএন্ড সার্ভারে বা উভয়েই যখন ত্রুটি ঘটেছে