ত্রুটি প্রতিক্রিয়া

স্ট্যান্ডার্ড ত্রুটি প্রতিক্রিয়া

যদি একটি রিপোর্টিং API অনুরোধ সফল হয়, API একটি 200 প্রদান করে। যদি একটি অনুরোধের সাথে একটি ত্রুটি ঘটে, API ত্রুটির ধরণের উপর ভিত্তি করে প্রতিক্রিয়াতে একটি HTTP স্থিতি কোড, স্থিতি এবং কারণ প্রদান করে। উপরন্তু, প্রতিক্রিয়ার মূল অংশে ত্রুটির কারণের একটি বিশদ বিবরণ রয়েছে। এখানে একটি ত্রুটি প্রতিক্রিয়া একটি উদাহরণ:

{
 "error": {
  "code": 403,
  "message": "User does not have sufficient permissions for this profile.",
  "status": "PERMISSION_DENIED"
 }
}

ত্রুটি টেবিল

কোড স্ট্যাটাস বর্ণনা সুপারিশকৃত কাজ
400 INVALID_ARGUMENT অনুরোধটি অবৈধ; একটি প্রয়োজনীয় যুক্তি অনুপস্থিত হতে পারে, সীমা অতিক্রম করতে পারে বা একটি অবৈধ মান থাকতে পারে৷ বিস্তারিত জানার জন্য ত্রুটি বার্তা পর্যালোচনা করুন. ক্লায়েন্ট পুনরায় চেষ্টা করলে এই ত্রুটিটি আবার ব্যর্থ হবে।
401 UNAUTHENTICATED ক্লায়েন্ট সঠিকভাবে প্রমাণীকরণ করা হয় না. সমস্যার সমাধান না করে আবার চেষ্টা করবেন না। আপনাকে একটি নতুন প্রমাণীকরণ টোকেন পেতে হবে।
403 PERMISSION_DENIED ব্যবহারকারীর অ্যাক্সেস নেই এমন ডেটার জন্য অনুরোধ নির্দেশ করে। সমস্যার সমাধান না করে আবার চেষ্টা করবেন না। নির্দিষ্ট সত্তায় অপারেশন করার জন্য আপনাকে পর্যাপ্ত অনুমতি পেতে হবে।
429 RESOURCE_EXHAUSTED Analyticsডিফল্টগ্রুপCLIENT_PROJECT-1d ইঙ্গিত করে যে প্রতিদিনের অনুরোধগুলি প্রতি প্রকল্পের কোটা শেষ হয়ে গেছে। সমস্যার সমাধান না করে আবার চেষ্টা করবেন না। আপনি আপনার প্রতিদিনের কোটা ব্যবহার করেছেন।
429 RESOURCE_EXHAUSTED Analyticsডিফল্টগ্রুপCLIENT_PROJECT-100s নির্দেশ করে যে প্রতি প্রকল্পের কোটা প্রতি 100 সেকেন্ডের অনুরোধগুলি শেষ হয়ে গেছে। সূচকীয় ব্যাক-অফ ব্যবহার করে পুনরায় চেষ্টা করুন। আপনি যে হারে অনুরোধ পাঠাচ্ছেন তার গতি কমাতে হবে।
429 RESOURCE_EXHAUSTED Analyticsডিফল্টগ্রুপ ব্যবহারকারী-100 নির্দেশ করে যে প্রতি প্রকল্পের কোটা প্রতি ব্যবহারকারী প্রতি 100 সেকেন্ডের অনুরোধগুলি শেষ হয়ে গেছে। সূচকীয় ব্যাক-অফ ব্যবহার করে পুনরায় চেষ্টা করুন। আপনি যে হারে অনুরোধ পাঠাচ্ছেন তার গতি কমাতে হবে।
429 RESOURCE_EXHAUSTED আবিষ্কার গ্রুপCLIENT_PROJECT-100s নির্দেশ করে যে প্রতি 100 সেকেন্ডের কোটা আবিষ্কারের অনুরোধগুলি শেষ হয়ে গেছে। আবিষ্কারের প্রতিক্রিয়া ঘন ঘন পরিবর্তন হয় না; স্থানীয়ভাবে আবিষ্কার প্রতিক্রিয়া ক্যাশে করুন বা সূচকীয় ব্যাক-অফ ব্যবহার করে পুনরায় চেষ্টা করুন। আপনি যে হারে অনুরোধ পাঠাচ্ছেন তার গতি কমাতে হবে।
500 INTERNAL অপ্রত্যাশিত অভ্যন্তরীণ সার্ভার ত্রুটি ঘটেছে. একবারের বেশি এই ক্যোয়ারীটি আবার চেষ্টা করবেন না।
503 BACKEND_ERROR সার্ভার একটি ত্রুটি ফিরিয়ে দিয়েছে৷ একবারের বেশি এই ক্যোয়ারীটি আবার চেষ্টা করবেন না।
503 UNAVAILABLE পরিষেবা অনুরোধ প্রক্রিয়া করতে অক্ষম ছিল. এটি সম্ভবত একটি ক্ষণস্থায়ী অবস্থা এবং সূচকীয় ব্যাক-অফ দিয়ে পুনরায় চেষ্টা করে সংশোধন করা যেতে পারে।

সূচকীয় ব্যাকঅফ বাস্তবায়ন

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

সাধারণ সূচকীয় ব্যাকঅফ বাস্তবায়নের জন্য প্রবাহ নিম্নরূপ।

  1. API এ একটি অনুরোধ করুন
  2. একটি ত্রুটির প্রতিক্রিয়া পান যাতে একটি পুনরায় চেষ্টা-সক্ষম ত্রুটি কোড রয়েছে৷
  3. 1s + random_number_milliseconds সেকেন্ড অপেক্ষা করুন
  4. অনুরোধ পুনরায় চেষ্টা করুন
  5. একটি ত্রুটির প্রতিক্রিয়া পান যাতে একটি পুনরায় চেষ্টা-সক্ষম ত্রুটি কোড রয়েছে৷
  6. 2s + random_number_milliseconds সেকেন্ড অপেক্ষা করুন
  7. অনুরোধ পুনরায় চেষ্টা করুন
  8. একটি ত্রুটির প্রতিক্রিয়া পান যাতে একটি পুনরায় চেষ্টা-সক্ষম ত্রুটি কোড রয়েছে৷
  9. 4s + random_number_milliseconds সেকেন্ড অপেক্ষা করুন
  10. অনুরোধ পুনরায় চেষ্টা করুন
  11. একটি ত্রুটির প্রতিক্রিয়া পান যাতে একটি পুনরায় চেষ্টা-সক্ষম ত্রুটি কোড রয়েছে৷
  12. 8s + random_number_milliseconds সেকেন্ড অপেক্ষা করুন
  13. অনুরোধ পুনরায় চেষ্টা করুন
  14. একটি ত্রুটির প্রতিক্রিয়া পান যাতে একটি পুনরায় চেষ্টা-সক্ষম ত্রুটি কোড রয়েছে৷
  15. 16s + random_number_milliseconds সেকেন্ড অপেক্ষা করুন
  16. অনুরোধ পুনরায় চেষ্টা করুন
  17. আপনি যদি এখনও একটি ত্রুটি পান, থামুন এবং ত্রুটি লগ.

উপরের প্রবাহে, random_number_milliseconds হল 1000 এর থেকে কম বা সমান মিলিসেকেন্ডের একটি এলোমেলো সংখ্যা। কিছু সমবর্তী বাস্তবায়নে নির্দিষ্ট লক ত্রুটি এড়াতে এটি প্রয়োজনীয়। random_number_milliseconds অবশ্যই প্রতিটি অপেক্ষার পরে পুনরায় সংজ্ঞায়িত করা উচিত।

দ্রষ্টব্য : অপেক্ষা সর্বদা হয় (2^n) + random_number_milliseconds , যেখানে n হল একটি একঘেয়ে ক্রমবর্ধমান পূর্ণসংখ্যা যা প্রাথমিকভাবে 0 হিসাবে সংজ্ঞায়িত করা হয়। n প্রতিটি পুনরাবৃত্তির (প্রতিটি অনুরোধ) জন্য 1 দ্বারা বৃদ্ধি করা হয়।

n 5 হলে অ্যালগরিদমটি সমাপ্ত হতে সেট করা হয়। এই সিলিংটি কেবলমাত্র ক্লায়েন্টদের অসীমভাবে পুনরায় চেষ্টা করা থেকে বিরত রাখার জন্য এবং এর ফলে একটি অনুরোধ "একটি পুনরুদ্ধারযোগ্য ত্রুটি" হিসাবে বিবেচিত হওয়ার আগে প্রায় 32 সেকেন্ডের মোট বিলম্ব হয়।

নিম্নলিখিত পাইথন কোডটি makeRequest নামে একটি পদ্ধতিতে ঘটে যাওয়া ত্রুটিগুলি থেকে পুনরুদ্ধারের জন্য উপরের প্রবাহের একটি বাস্তবায়ন।

import random
import time
from apiclient.errors import HttpError

def makeRequestWithExponentialBackoff(analytics):
  """Wrapper to request Google Analytics data with exponential backoff.

  The makeRequest method accepts the analytics service object, makes API
  requests and returns the response. If any error occurs, the makeRequest
  method is retried using exponential backoff.

  Args:
    analytics: The analytics service object

  Returns:
    The API response from the makeRequest method.
  """
  for n in range(0, 5):
    try:
      return makeRequest(analytics)

    except HttpError, error:
      if error.resp.reason in ['userRateLimitExceeded', 'quotaExceeded',
                               'internalServerError', 'backendError']:
        time.sleep((2 ** n) + random.random())
      else:
        break

  print "There has been an error, the request never succeeded."