ଏକ ପ୍ରକ୍ସି ପୁଲ ସରଳ ବ୍ୟାଘାତକୁ ବ୍ୟସ୍ତ ଲୁପରେ ପରିଣତ କରିପାରେ। ଏକ ଠିକଣା ବାଛନ୍ତୁ, ବିଫଳ ହୁଏ, ଅନ୍ୟଟି ବାଛନ୍ତୁ, ପୁଣି ବିଫଳ ହୁଏ। ଯଦି ପ୍ରତ୍ୟେକ ଏଣ୍ଡପଏଣ୍ଟ ପହଞ୍ଚାଯାଇ ନ ପାରେ କାରଣ ଆପଣଙ୍କ ନିଜ ନେଟୱାର୍କ ବନ୍ଦ ଅଛି, ଠିକଣା ବଦଳାଇବା କେବେ କାରଣ ସମାଧାନ କରିବ ନାହିଁ।

ଆପଣଙ୍କ ପୁଲରୁ ପ୍ରଥମ ପ୍ରକ୍ସି କିମ୍ବା ମାଗଣା ପ୍ରକ୍ସି ତାଲିକା ବାଛିବା ପୂର୍ବରୁ କାର୍ଯ୍ୟକୁ ବଜେଟ୍ ଦିଅନ୍ତୁ: ସୀମିତ ସଂଖ୍ୟକ ପ୍ରଚେଷ୍ଟା, ସୀମିତ ସଂଯୋଗ ଓ ପଠନ ଅପେକ୍ଷା, ଏବଂ ସମଗ୍ର କାର୍ଯ୍ୟ ପାଇଁ ଏକ ସମୟସୀମା। Requests ଟାଇମଆଉଟ ଏହାର ନଥିଭୁକ୍ତ ସଂଯୋଗ କିମ୍ବା ପଠନ ଆଚରଣ ନିୟନ୍ତ୍ରଣ କରେ; ଏହା ନିଜେ ନୂଆ ଅନୁରୋଧ ଜାରି କରୁଥିବା ଲୁପକୁ ସୀମିତ କରେ ନାହିଁ।

କେଉଁଟି ଆଉ ଏକ ପ୍ରଚେଷ୍ଟା ପାଇବାର ଯୋଗ୍ୟ ତାହା ନିର୍ଣ୍ଣୟ କରନ୍ତୁ

  • ପ୍ରତ୍ୟାଖ୍ୟାନ ହୋଇଥିବା ପ୍ରକ୍ସି ସଂଯୋଗ ଅନ୍ୟ ଏକ ଏଣ୍ଡପଏଣ୍ଟ ଚେଷ୍ଟା କରିବାର ଯୁକ୍ତି ଦେଇପାରେ।
  • ଗନ୍ତବ୍ୟର ପ୍ରତିକ୍ରିୟାର ନିଜସ୍ୱ ବ୍ୟାଖ୍ୟା ଆବଶ୍ୟକ। HTTP ତ୍ରୁଟି ପାଇବା ପ୍ରମାଣ କରେ ଯେ କୌଣସି ଅନୁରୋଧ ପଥ ସମ୍ପୂର୍ଣ୍ଣ ହୋଇଛି।
  • ପ୍ରକ୍ସି ପ୍ରମାଣୀକରଣ ବିଫଳତା ଏଣ୍ଡପଏଣ୍ଟ ଓ ଖାତା ଯାଞ୍ଚ କରିବା ଆବଶ୍ୟକ କରେ, ବଢ଼ୁଥିବା ତାଲିକାରେ ସମାନ ପ୍ରମାଣପତ୍ର ମାରିବା ପରିବର୍ତ୍ତେ।

ମୂଳ ବ୍ୟତିକ୍ରମ କିମ୍ବା ସ୍ଥିତି ପ୍ରଚେଷ୍ଟା ରେକର୍ଡ ସହିତ ରଖନ୍ତୁ। କେବଳ “ସମସ୍ତ ପ୍ରକ୍ସି ବିଫଳ ହେଲା” ଥିବା ଅନ୍ତିମ ସନ୍ଦେଶ ବିଫଳତାଗୁଡ଼ିକର କାରଣ ଏକ ଥିଲା କି ନାହିଁ ଲୁଚାଏ।

ପ୍ରତ୍ୟେକ ପ୍ରକୃତ ଅନୁରୋଧ ପୂର୍ବରୁ ପ୍ରତ୍ୟେକ ପ୍ରକ୍ସିର ସ୍ୱାସ୍ଥ୍ୟ ଯାଞ୍ଚ କରିବା ଆଉ ଏକ ଅନୁରୋଧ ଯୋଡ଼େ ଏବଂ ପରବର୍ତ୍ତୀଟି ସଫଳ ହେବ ବୋଲି ତଥାପି ନିଶ୍ଚିତ କରିପାରେ ନାହିଁ। କାର୍ଯ୍ୟ ସହିତ ଉପଯୁକ୍ତ ସ୍ଥାନରେ ସାମ୍ପ୍ରତିକ ସ୍ୱାସ୍ଥ୍ୟ ତଥ୍ୟ ପୁନଃ ବ୍ୟବହାର କରନ୍ତୁ, ତାପରେ ପ୍ରକୃତ କାର୍ଯ୍ୟକୁ ନିଜ ଫଳାଫଳ ଜଣାଇବାକୁ ଦିଅନ୍ତୁ।

ପୁନଃ ପ୍ରଚେଷ୍ଟା କାର୍ଯ୍ୟକୁ ପୁନରାବୃତ୍ତି କରିପାରେ

କେବଳ ପଠନ ପାଇଁ ଆଣିବାରେ ଅନ୍ୟ ପ୍ରକ୍ସିକୁ ଯିବା ସାଧାରଣତଃ ଦାଖଲ ପୁନଃ ଚଲାଇବା ଅପେକ୍ଷା ସରଳ। ଯଦି କ୍ରୟ କିମ୍ବା ଫର୍ମ ଦାଖଲ ପଠାଇବା ପରେ ସଂଯୋଗ ଛିଣ୍ଡିଯାଏ, ଗନ୍ତବ୍ୟ ଏହାକୁ ପୂର୍ବରୁ ପ୍ରକ୍ରିୟା କରିଥାଇପାରେ। କାର୍ଯ୍ୟ ପୁନଃ ଚଲାଇବା ପୂର୍ବରୁ ସେବାର idempotency ବ୍ୟବସ୍ଥା ଏବଂ HTTP ପୁନଃ ପ୍ରଚେଷ୍ଟା ନିୟମ ଅନୁସରଣ କରନ୍ତୁ।

ବଜେଟ୍ ଶେଷ ହେଲେ ଏକ ଉପଯୋଗୀ ବିଫଳତା ଫେରାନ୍ତୁ। ପ୍ରମାଣ ସହିତ ଅଟକିବା କାର୍ଯ୍ୟ କାହାର ଧ୍ୟାନକୁ ଆସିବା ପର୍ଯ୍ୟନ୍ତ ଚୁପଚାପ୍ ଘୂରୁଥିବା କାର୍ଯ୍ୟଠାରୁ ମରାମତି କରିବା ସହଜ।

ସମ୍ପର୍କିତ ପ୍ରବନ୍ଧ