এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

499 ক্লায়েন্ট বন্ধ সংযোগ

আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন .info- তে যান।

লক্ষণ

ক্লায়েন্ট অ্যাপ্লিকেশনটি এপিআই অনুরোধের জন্য একটি টাইমআউট ত্রুটি পায় অথবা Apigee-তে এপিআই অনুরোধটি কার্যকর থাকা অবস্থায় অনুরোধটি হঠাৎ করে বন্ধ হয়ে যায়।

এই ধরনের এপিআই অনুরোধগুলির জন্য আপনি এপিআই মনিটরিং এবং এনজিআইএনএক্স অ্যাক্সেস লগগুলিতে স্ট্যাটাস কোড 499 দেখতে পাবেন। কখনও কখনও, আপনি এপিআই অ্যানালিটিক্সে ভিন্ন স্ট্যাটাস কোড দেখতে পারেন, কারণ এটি মেসেজ প্রসেসর দ্বারা ফেরত দেওয়া স্ট্যাটাস কোডটি দেখায়।

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

ক্লায়েন্ট অ্যাপ্লিকেশনগুলিতে নিম্নলিখিত ধরনের ত্রুটি দেখা যেতে পারে:

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received

ক্লায়েন্ট টাইমআউটের কারণ কী?

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

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

ক্লায়েন্টে সময়সীমা শেষ

আপনার প্রয়োজন অনুযায়ী ক্লায়েন্ট অ্যাপ্লিকেশনগুলোতে একটি উপযুক্ত টাইমআউট মান কনফিগার করা যেতে পারে।

ওয়েব ব্রাউজার এবং মোবাইল অ্যাপের মতো ক্লায়েন্টগুলোর জন্য অপারেটিং সিস্টেম দ্বারা নির্ধারিত টাইমআউট থাকে।

রাউটারে টাইমআউট

রাউটারগুলিতে ডিফল্টভাবে কনফিগার করা টাইমআউট হলো ৫৭ সেকেন্ড। Edge-এ API অনুরোধটি গৃহীত হওয়ার সময় থেকে শুরু করে ব্যাকএন্ডের প্রতিক্রিয়া এবং কার্যকর হওয়া সমস্ত পলিসি সহ প্রতিক্রিয়াটি ফেরত পাঠানো পর্যন্ত, একটি API প্রক্সি সর্বোচ্চ এই পরিমাণ সময় পর্যন্ত কার্যকর থাকতে পারে। "রাউটারগুলিতে I/O টাইমআউট কনফিগার করা" অংশে যেমন ব্যাখ্যা করা হয়েছে, সেই অনুযায়ী রাউটার এবং ভার্চুয়াল হোস্টগুলিতে এই ডিফল্ট টাইমআউটকে ওভাররাইড করা যেতে পারে।

মেসেজ প্রসেসরগুলিতে সময়সীমা অতিক্রান্ত

মেসেজ প্রসেসরগুলিতে ডিফল্টভাবে ৫৫ সেকেন্ডের টাইমআউট কনফিগার করা থাকে। ব্যাকএন্ড সার্ভার অনুরোধটি প্রসেস করে মেসেজ প্রসেসরকে উত্তর পাঠাতে সর্বোচ্চ এই পরিমাণ সময় নিতে পারে । "মেসেজ প্রসেসরগুলিতে I/O টাইমআউট কনফিগার করা" অংশে যেমন ব্যাখ্যা করা হয়েছে, সেই অনুযায়ী মেসেজ প্রসেসরগুলিতে অথবা এপিআই প্রক্সির মধ্যে এই ডিফল্ট টাইমআউটকে ওভাররাইড করা যেতে পারে।

যদি এপিআই প্রক্সির টাইম আউট হওয়ার আগেই ক্লায়েন্ট রাউটারের সাথে সংযোগ বিচ্ছিন্ন করে দেয়, তাহলে আপনি নির্দিষ্ট এপিআই অনুরোধটির জন্য টাইম আউট ত্রুটি দেখতে পাবেন। এই ধরনের অনুরোধের জন্য রাউটারে স্ট্যাটাস কোড 499 Client Closed Connection লগ করা হয়, যা এপিআই মনিটরিং এবং এনজিআইএনএক্স অ্যাক্সেস লগে দেখা যায়।

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

Edge ব্রাউজারে 499 Client Closed Connection এররটির সাধারণ কারণগুলো হলো:

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

সাধারণ রোগ নির্ণয়ের পদক্ষেপ

এই ত্রুটি নির্ণয় করতে নিম্নলিখিত সরঞ্জাম/কৌশলগুলোর মধ্যে যেকোনো একটি ব্যবহার করুন:

এপিআই মনিটরিং
NGINX অ্যাক্সেস লগ

এপিআই মনিটরিং

এপিআই মনিটরিং ব্যবহার করে ত্রুটি নির্ণয় করতে:

Analyze > API Monitoring > Investigate পৃষ্ঠায় যান।
4xx ত্রুটিগুলির জন্য ফিল্টার করুন এবং সময়সীমা নির্বাচন করুন।
সময়ের সাপেক্ষে স্ট্যাটাস কোড প্লট করুন।
নীচে দেখানো অনুযায়ী যে সেলটিতে 499 ত্রুটি রয়েছে, সেটি নির্বাচন করুন:
আপনি ডানদিকের প্যানেলে 499 ত্রুটি সম্পর্কিত তথ্য দেখতে পাবেন, যেমনটি নিচে দেখানো হয়েছে:
ডানদিকের প্যানেলে, 'লগ দেখুন' (View logs) -এ ক্লিক করুন।
ট্র্যাফিক লগস উইন্ডো থেকে, কিছু 499 এররের জন্য নিম্নলিখিত বিবরণগুলি নোট করুন:
- অনুরোধ : এটি কল করার জন্য ব্যবহৃত অনুরোধ পদ্ধতি এবং URI প্রদান করে।
- প্রতিক্রিয়া সময় : এটি অনুরোধটির জন্য অতিবাহিত মোট সময় প্রদান করে।
দ্রষ্টব্য : HTTP 499 ত্রুটির ক্ষেত্রে নিম্নলিখিত ফিল্ডগুলিতে - মানটি প্রদর্শিত হবে:
- ত্রুটির উৎস
- ত্রুটি কোড
- ফল্ট ফ্লো
- ত্রুটি নীতি
- ফল্ট প্রক্সি
এই ফিল্ডগুলি মেসেজ প্রসেসর দ্বারা পূরণ করা হয় এবং রাউটার মেসেজ প্রসেসরের কাছ থেকে প্রতিক্রিয়া পেলেই কেবল এগুলিতে উপযুক্ত মান সেট করা হবে। এই ক্ষেত্রে, রাউটার মেসেজ প্রসেসরের কাছ থেকে প্রতিক্রিয়া পাওয়ার আগেই ক্লায়েন্ট অ্যাপ্লিকেশনটি রাউটারের সাথে সংযোগটি বন্ধ করে দিয়েছে। এটি রাউটারকে স্ট্যাটাস কোড 499 এ সেট করতে বাধ্য করে এবং ফলস্বরূপ উপরে উল্লিখিত সমস্ত ফিল্ড - হিসাবে প্রদর্শিত হয়।
আপনি এপিআই মনিটরিং GET লগস এপিআই ব্যবহার করেও সমস্ত লগ পেতে পারেন। উদাহরণস্বরূপ, org , env , timeRange , এবং status দিয়ে লগ কোয়েরি করার মাধ্যমে, আপনি সেইসব ট্রানজ্যাকশনের সমস্ত লগ ডাউনলোড করতে পারবেন যেখানে ক্লায়েন্টের টাইম আউট হয়েছে।
যেহেতু এপিআই মনিটরিং HTTP 499 ত্রুটির জন্য প্রক্সিকে - এ সেট করে, তাই আপনি ভার্চুয়াল হোস্ট এবং পাথের জন্য সংশ্লিষ্ট প্রক্সি পেতে এপিআই ( লগস এপিআই ) ব্যবহার করতে পারেন।
উদাহরণস্বরূপ :
```
curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
```
অতিরিক্ত 499 এররগুলোর জন্য রেসপন্স টাইম পর্যালোচনা করুন এবং পরীক্ষা করে দেখুন যে সমস্ত 499 এরর জুড়ে রেসপন্স টাইমটি সামঞ্জস্যপূর্ণ (ধরা যাক ৩০ সেকেন্ড) কিনা।

NGINX অ্যাক্সেস লগ

NGINX অ্যাক্সেস লগ ব্যবহার করে ত্রুটি নির্ণয় করতে:

আপনি যদি একজন প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে HTTP 499 ত্রুটি সম্পর্কিত মূল তথ্য নির্ধারণ করতে NGINX অ্যাক্সেস লগ ব্যবহার করতে পারেন।
NGINX অ্যাক্সেস লগগুলি পরীক্ষা করুন:
/opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log
একটি নির্দিষ্ট সময়কালে কোনো 499 এরর ছিল কিনা (যদি সমস্যাটি অতীতে ঘটে থাকে) অথবা এখনও কোনো রিকোয়েস্ট 499 কারণে ফেইল করছে কিনা তা খুঁজে দেখুন।
499 ত্রুটির মধ্যে কয়েকটির জন্য নিম্নলিখিত তথ্যগুলো লক্ষ্য করুন:
- মোট প্রতিক্রিয়া সময়
- অনুরোধ URI
- ব্যবহারকারী এজেন্ট
NGINX অ্যাক্সেস লগ থেকে প্রাপ্ত ৪৯৯ ত্রুটির নমুনা :
```
2019-08-23T06:50:07+00:00       rrt-03f69eb1091c4a886-c-sy      50.112.119.65:47756
10.10.53.154:8443       10.001  -       -       499     -       422     0
   GET /v1/products HTTP/1.1        -       okhttp/3.9.1    api.acme.org
rrt-03f69eb1091c4a886-c-sy-13001-6496714-1
    50.112.119.65   -       -       -       -       -       -       -       -1      -       -       dc-1  router-pod-1
rt-214-190301-0020137-latest-7d
36       TLSv1.2 gateway-1     dc-1  acme    prod  https   -
```
এই উদাহরণে, আমরা নিম্নলিখিত তথ্য দেখতে পাই:
- মোট প্রতিক্রিয়া সময়: 10.001 সেকেন্ড। এর অর্থ হলো, ১০.০০১ সেকেন্ড পর ক্লায়েন্টের সময়সীমা শেষ হয়ে গেছে।
- অনুরোধ: GET /v1/products
- হোস্ট : api.acme.org
- ব্যবহারকারী এজেন্ট: okhttp/3.9.1
সমস্ত 499 এররের ক্ষেত্রে মোট প্রতিক্রিয়া সময় এবং ইউজার এজেন্ট সামঞ্জস্যপূর্ণ কিনা তা পরীক্ষা করে দেখুন।

কারণ: ক্লায়েন্ট হঠাৎ করে সংযোগটি বন্ধ করে দিয়েছে

রোগ নির্ণয়

যখন ব্রাউজার বা মোবাইল অ্যাপ্লিকেশনে চলমান কোনো সিঙ্গেল পেজ অ্যাপ থেকে কোনো এপিআই (API) কল করা হয়, তখন যদি ব্যবহারকারী হঠাৎ করে ব্রাউজারটি বন্ধ করে দেন, একই ট্যাবের অন্য কোনো ওয়েবপেজে চলে যান, অথবা স্টপ লোডিং' -এ ক্লিক বা ট্যাপ করে পেজটি লোড হওয়া বন্ধ করে দেন, তাহলে ব্রাউজারটি অনুরোধটি বাতিল করে দেবে।
এর ফলে, HTTP 499 স্ট্যাটাসযুক্ত ট্রানজ্যাকশনগুলোর ক্ষেত্রে প্রতিটি রিকোয়েস্টের প্রসেসিং টাইম ( রেসপন্স টাইম ) সাধারণত ভিন্ন ভিন্ন হয়ে থাকে।
সাধারণ রোগ নির্ণয়ের ধাপগুলিতে যেমন ব্যাখ্যা করা হয়েছে, সেই অনুযায়ী API মনিটরিং বা NGINX অ্যাক্সেস লগ ব্যবহার করে প্রতিটি 499 ত্রুটির জন্য রেসপন্স টাইম তুলনা করে এবং তা ভিন্ন কিনা তা যাচাই করে আপনি এটিই কারণ কিনা তা নির্ধারণ করতে পারেন।

সমাধান

এটি স্বাভাবিক এবং যদি HTTP 499 ত্রুটিগুলি অল্প সংখ্যায় ঘটে, তবে এটি সাধারণত উদ্বেগের কারণ নয়।
যদি একই URL পাথের ক্ষেত্রে এটি প্রায়শই ঘটে, তাহলে এর কারণ হতে পারে যে ওই পাথের সাথে যুক্ত নির্দিষ্ট প্রক্সিটি খুব ধীরগতির এবং ব্যবহারকারীরা অপেক্ষা করতে ইচ্ছুক নন।
কোন প্রক্সিটি প্রভাবিত হতে পারে তা জানার পর, প্রক্সি ল্যাটেন্সির কারণ আরও বিশদভাবে অনুসন্ধান করতে ল্যাটেন্সি অ্যানালাইসিস ড্যাশবোর্ডটি ব্যবহার করুন।
1. এক্ষেত্রে, ‘সাধারণ রোগনির্ণয়ের ধাপসমূহ’ -তে উল্লিখিত পদক্ষেপগুলো ব্যবহার করে প্রভাবিত প্রক্সিটি নির্ধারণ করুন।
2. প্রক্সি লেটেন্সির কারণ আরও বিশদভাবে অনুসন্ধান করতে এবং সমস্যাটি সমাধান করতে লেটেন্সি অ্যানালাইসিস ড্যাশবোর্ডটি ব্যবহার করুন।
3. যদি আপনি দেখেন যে নির্দিষ্ট প্রক্সিটির জন্য বিলম্ব প্রত্যাশিত, তাহলে আপনাকে আপনার ব্যবহারকারীদের জানাতে হতে পারে যে এই প্রক্সিটির প্রতিক্রিয়া জানাতে কিছুটা সময় লাগবে।

কারণ: ক্লায়েন্ট অ্যাপ্লিকেশন টাইমআউট

এটি বিভিন্ন পরিস্থিতিতে ঘটতে পারে।

স্বাভাবিক অপারেটিং পরিস্থিতিতে অনুরোধটি সম্পন্ন হতে একটি নির্দিষ্ট সময় (ধরা যাক ১০ সেকেন্ড) লাগার কথা। কিন্তু, ক্লায়েন্ট অ্যাপ্লিকেশনটিতে একটি ভুল টাইমআউট মান (ধরা যাক ৫ সেকেন্ড) সেট করা আছে, যার ফলে এপিআই অনুরোধটি সম্পন্ন হওয়ার আগেই অ্যাপ্লিকেশনটি টাইমআউট হয়ে যায় এবং 499 এরর দেখা দেয়। এক্ষেত্রে, আমাদের ক্লায়েন্ট টাইমআউটটি একটি উপযুক্ত মানে সেট করতে হবে।
টার্গেট সার্ভার বা কলআউট প্রত্যাশার চেয়ে বেশি সময় নিচ্ছে। এক্ষেত্রে, আপনাকে উপযুক্ত কম্পোনেন্টটি ঠিক করতে হবে এবং সেই সাথে টাইমআউটের মানগুলোও যথাযথভাবে সমন্বয় করতে হবে।
ক্লায়েন্টের আর প্রতিক্রিয়াটির প্রয়োজন ছিল না এবং তাই এটি বাতিল করা হয়েছে। অটো-কমপ্লিট বা শর্ট পোলিং-এর মতো উচ্চ ফ্রিকোয়েন্সির এপিআই-এর ক্ষেত্রে এমনটা ঘটতে পারে।

রোগ নির্ণয়

এপিআই মনিটরিং বা এনজিআইএনএক্স অ্যাক্সেস লগ

এপিআই মনিটরিং অথবা এনজিআইএনএক্স অ্যাক্সেস লগ ব্যবহার করে ত্রুটিটি নির্ণয় করুন:

সাধারণ রোগ নির্ণয়ের ধাপগুলিতে যেমন ব্যাখ্যা করা হয়েছে, সেই অনুযায়ী HTTP 499 ট্রানজ্যাকশনগুলির জন্য API মনিটরিং লগ অথবা NGINX অ্যাক্সেস লগ পরীক্ষা করুন।
499 ত্রুটির সবগুলোর ক্ষেত্রে প্রতিক্রিয়া সময় (Response Time) সামঞ্জস্যপূর্ণ কিনা তা নির্ণয় করুন।
যদি হ্যাঁ হয়, তাহলে এমন হতে পারে যে কোনো নির্দিষ্ট ক্লায়েন্ট অ্যাপ্লিকেশন তার প্রান্তে একটি নির্দিষ্ট টাইমআউট কনফিগার করেছে। যদি কোনো এপিআই প্রক্সি বা টার্গেট সার্ভার ধীরগতিতে সাড়া দেয়, তাহলে প্রক্সির টাইমআউট হওয়ার আগেই ক্লায়েন্টের টাইমআউট হয়ে যাবে, যার ফলে একই URI পাথের জন্য প্রচুর পরিমাণে HTTP 499s ত্রুটি দেখা দেবে। এই ক্ষেত্রে, NGINX অ্যাক্সেস লগ থেকে ইউজার এজেন্ট (User Agent) নির্ধারণ করুন, যা আপনাকে নির্দিষ্ট ক্লায়েন্ট অ্যাপ্লিকেশনটি শনাক্ত করতে সাহায্য করবে।
এমনও হতে পারে যে Apigee-এর সামনে Akamai, F5, AWS ELB ইত্যাদির মতো কোনো লোড ব্যালেন্সার রয়েছে। যদি Apigee একটি কাস্টম লোড ব্যালেন্সারের পিছনে চলে, তবে লোড ব্যালেন্সারের রিকোয়েস্ট টাইমআউট অবশ্যই Apigee API টাইমআউটের চেয়ে বেশি করে কনফিগার করতে হবে। ডিফল্টরূপে, Apigee রাউটার ৫৭ সেকেন্ড পরে টাইমআউট হয়ে যায়, তাই লোড ব্যালেন্সারে ৬০ সেকেন্ডের একটি রিকোয়েস্ট টাইমআউট কনফিগার করা উপযুক্ত।

ট্রেস

ট্রেস ব্যবহার করে ত্রুটি নির্ণয় করুন।

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

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

সমাধান

Apigee Edge-এর মাধ্যমে API অনুরোধ প্রবাহে জড়িত বিভিন্ন উপাদানে কী টাইমআউট মান সেট করা উচিত, তা বোঝার জন্য I/O টাইমআউট কনফিগার করার সর্বোত্তম অনুশীলনগুলি দেখুন।
সর্বোত্তম অনুশীলন অনুযায়ী ক্লায়েন্ট অ্যাপ্লিকেশনে একটি উপযুক্ত টাইমআউট মান সেট করা নিশ্চিত করুন।

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

রোগ নির্ণয়ের তথ্য অবশ্যই সংগ্রহ করতে হবে

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

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

সংস্থার নাম
পরিবেশের নাম
এপিআই প্রক্সি নাম
টাইমআউট ত্রুটিটি পুনরুৎপাদন করতে ব্যবহৃত সম্পূর্ণ curl কমান্ড।
যে API অনুরোধগুলির জন্য আপনি ক্লায়েন্ট টাইমআউট ত্রুটি দেখতে পাচ্ছেন, সেগুলির ট্রেস ফাইল।

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

ব্যর্থ অনুরোধগুলির জন্য সম্পূর্ণ ত্রুটি বার্তা পরিলক্ষিত হয়েছে।
পরিবেশের নাম
এপিআই প্রক্সি বান্ডেল
যে API অনুরোধগুলির জন্য আপনি ক্লায়েন্ট টাইমআউট ত্রুটি দেখতে পাচ্ছেন, সেগুলির ট্রেস ফাইল।
NGINX অ্যাক্সেস লগ ( /opt/apigee/var/log/edge-router/nginx/ ORG ~ ENV . PORT# _access_log )
মেসেজ প্রসেসর সিস্টেম লগ ( /opt/apigee/var/log/edge-message-processor/logs/system.log )