প্রক্সির মাধ্যমে Kafka: bootstrap কাজ করে, broker সংযোগ ব্যর্থ হয়

Kafka ক্লায়েন্ট এখনও produce বা consume করতে না পারলেও bootstrap সংযোগ সফল হতে পারে। Bootstrap সার্ভারগুলো ক্লায়েন্টকে cluster আবিষ্কার করতে সাহায্য করে; সেগুলো ক্লায়েন্টের সংযুক্ত হওয়া একমাত্র endpoint নাও হতে পারে।

Broker metadata-তে পরবর্তী সংযোগের জন্য ব্যবহৃত ঠিকানাগুলো থাকে। যদি সেই নাম বা port গুলো নির্ধারিত প্রক্সি পথে পৌঁছানো না যায়, তাহলে প্রথম সফল সংযোগ বাকি কাজ সমাধান করে না।

ঘোষিত endpoint গুলো পড়ুন

Bootstrap ঠিকানার সঙ্গে ক্লায়েন্ট আসলে যে broker ঠিকানাগুলো পায় তা তুলনা করুন। একটি public bootstrap alias private ঘোষিত নামে নিয়ে যেতে পারে, আর একটি local port forward করলে metadata-র প্রতিটি ঠিকানা স্বয়ংক্রিয়ভাবে পুনর্লিখিত হয় না।

ক্লায়েন্ট বাস্তবায়ন কোন প্রক্সি পথ সমর্থন করে তাও চিহ্নিত করুন। Java system SOCKS property এই নিশ্চয়তা দেয় না যে কোনো library-র NIO-ভিত্তিক transport JDK Socket প্রক্সি প্রক্রিয়া ব্যবহার করে। প্রতিটি Java socket একই সেটিং মানে ধরে নেওয়ার বদলে প্রকৃত Kafka ক্লায়েন্ট ও network integration পরীক্ষা করুন।

প্রক্সি-সচেতন ক্লায়েন্টের সংশ্লিষ্ট broker endpoint-এ অনুমোদিত পথ দরকার। network-স্তরের ব্যবস্থার প্রয়োজন সংশ্লিষ্ট reachability ও name resolution। এগুলো ভিন্ন নকশা; শুধু একটি প্রক্সিকে bootstrap server হিসেবে তালিকাভুক্ত করলে কোনোটিই পাওয়া যায় না।

Security protocol ও authentication সেটিং আলাদা রাখুন। একটি প্রক্সি TCP পথ তৈরি করতে পারে, কিন্তু TLS identity, SASL authentication বা broker authorization তখনও ব্যর্থ হতে পারে।

Diagnosis-এর জন্য কোন endpoint ব্যর্থ হয়েছে এবং তা static configuration থেকে এসেছে নাকি ফেরত পাওয়া metadata থেকে এসেছে তা লক্ষ করুন। এই পার্থক্য ইতিমধ্যে পৌঁছানো যায় এমন endpoint বারবার বদলানোর চেয়ে সমস্যাটি অনেক বেশি সংকুচিত করে।