Squid ରେ retry_on_error ନାମକ ଏକ ବିକଳ୍ପ ଅଛି, କିନ୍ତୁ ନାମଟି ଏହାର ଉପଯୋଗୀ ବ୍ୟାଖ୍ୟାଠାରୁ ଅଧିକ ପ୍ରଶସ୍ତ। ଏହାର ଅର୍ଥ ନୁହେଁ ଯେ ପ୍ରତ୍ୟେକ ବିଫଳ ଅନୁରୋଧ ପୃଷ୍ଠା କାମ ନକରିବା ପର୍ଯ୍ୟନ୍ତ ଅସୀମିତ ଭାବରେ ପୁନରାବୃତ୍ତି ହେବ।

ଏହି ନିର୍ଦ୍ଦେଶକୁ ସମର୍ଥନ କରୁଥିବା ସଂସ୍କରଣଗୁଡ଼ିକରେ ଏହା ଡିଫଲ୍ଟ ଭାବରେ ବନ୍ଦ ଅଛି। ଦଲିଲଭୁକ୍ତ ପୁନରାବୃତ୍ତି ତାଲିକା ହେଉଛି 403, 500, 501, 502, 503 ଏବଂ 504, ଏବଂ ଏହା ଅନୁରୋଧକୁ ଅନ୍ୟ ଏକ କାର୍ଯ୍ୟକ୍ଷମ ଗନ୍ତବ୍ୟ ମାଧ୍ୟମରେ ଚେଷ୍ଟା କରେ। ବିକଳ୍ପ ଫରୱାର୍ଡିଂ ପଥ ଥିବା ପଦାନୁକ୍ରମରେ ଏହା ବିଶେଷ ପ୍ରାସଙ୍ଗିକ। ଏହା କେବଳ ସେହି ସକେଟରୁ ସେହି ସର୍ଭରକୁ ସମୟବଦ୍ଧ ପୁନଃପ୍ରୟାସ ନୁହେଁ।

ପ୍ରଥମେ ବିଫଳତାର ନାମ ଦିଅନ୍ତୁ

ପ୍ରକ୍ସି ସହିତ ସଂଯୋଗ ସମୟରେ ପ୍ରତ୍ୟାଖ୍ୟାନ, ପ୍ରକ୍ସି ପ୍ରମାଣୀକରଣ ବିଫଳତା, ମୂଳରୁ HTTP ତ୍ରୁଟି ଏବଂ ବିତରଣ ଆରମ୍ଭ ପରେ କଟିଯାଇଥିବା ପ୍ରତିକ୍ରିୟା ସମାନ ପୁନଃପ୍ରୟାସ ସୁଯୋଗ ଦିଏ ନାହିଁ। ଗୋଟିଏ ସେଟିଂ ଚାରିଟିକୁ ସମାନ ଭାବରେ ସମ୍ଭାଳିବ ବୋଲି ଆଶା କରନ୍ତୁ ନାହିଁ।

ଘରୋଇ ପ୍ରସ୍ଥାନ ପାଇଁ ବିକଳ୍ପ ପଥ ଗ୍ରହଣୀୟ କି ନାହିଁ ମଧ୍ୟ ସ୍ଥିର କରନ୍ତୁ। ଅନ୍ୟ ଏକ ପିତୃ ପାଖରେ ଅନ୍ୟ ଏକ ସାର୍ବଜନୀନ ଉତ୍ସ ଠିକଣା, ପ୍ରମାଣୀକରଣ ନୀତି କିମ୍ବା ନେଟୱାର୍କ ସ୍ଥାନ ଥାଇପାରେ। ସେହି ବିକଳ୍ପ ମାଧ୍ୟମରେ ସଫଳତା ପ୍ରଥମ ପିତୃକୁ ବାଛିବାର କାରଣକୁ ଉଲ୍ଲଂଘନ କରିପାରେ।

ଆପଣ କାର୍ଯ୍ୟାନୁଷ୍ଠାନ ଆଉ ଏକ ଚିନ୍ତା ଆଣେ: ଅନୁରୋଧ ପୁନରାବୃତ୍ତି କଲେ ଏହାର ପ୍ରଭାବ ମଧ୍ୟ ପୁନରାବୃତ୍ତି ହୋଇପାରେ। କ୍ଲାୟେଣ୍ଟ ଏବଂ ସର୍ଭରକୁ ଉପଯୁକ୍ତ ପୁନଃପ୍ରୟାସ ସେମାଣ୍ଟିକ୍ସ ଆବଶ୍ୟକ, ବିଶେଷକରି ଡାଟା ସୃଷ୍ଟି କିମ୍ବା ପରିବର୍ତ୍ତନ କରୁଥିବା କାର୍ଯ୍ୟାନୁଷ୍ଠାନ ପାଇଁ। ପ୍ରକ୍ସି ସେଟିଂ ଅନିଶ୍ଚିତ ଫଳାଫଳର ଆପ୍ଲିକେସନ୍ ସ୍ତରୀୟ ପରିଚାଳନାର ବିକଳ୍ପ ନୁହେଁ।

ଆପଣଙ୍କ ସଠିକ୍ ସଂସ୍କରଣ ପାଇଁ ନିର୍ଦ୍ଦେଶ ପଢ଼ନ୍ତୁ; ସନ୍ଦର୍ଭରେ ଉପଲବ୍ଧତା ଏବଂ ଡିଫଲ୍ଟ ଆଚରଣ ତାଲିକାଭୁକ୍ତ ଅଛି। ସାଙ୍ଗରେ ଅନୁରୋଧ ସମୟସୀମା ଏବଂ ଉପଭୋକ୍ତାଙ୍କୁ ଦେଖାଯାଉଥିବା ମୋଟ ଅପେକ୍ଷା ମଧ୍ୟ ଧ୍ୟାନରେ ରଖନ୍ତୁ। ଅତିରିକ୍ତ ଫରୱାର୍ଡିଂ ପ୍ରୟାସ ଭଲ ଫଳାଫଳ ନଦେଇ ବାକି ସମୟ ଖର୍ଚ୍ଚ କରିପାରେ।

ମଧ୍ୟରେ ମଧ୍ୟରେ ଘଟୁଥିବା ବିଫଳତା ଅନୁସନ୍ଧାନ କରିବା ସମୟରେ ସ୍ଥିତି, ମନୋନୀତ ପିତୃ କିମ୍ବା ଗନ୍ତବ୍ୟ ଏବଂ ପ୍ରୟାସର କ୍ରମ ରେକର୍ଡ କରନ୍ତୁ। ନଚେତ୍ ପୁନରାବୃତ୍ତି ବାରମ୍ବାର ଘଟୁଥିବା ରାଉଟିଂ ସମସ୍ୟାକୁ ସାଧାରଣତଃ ମନ୍ଥର ୱେବସାଇଟ୍ ପରି ଦେଖାଇପାରେ ଏବଂ ପ୍ରକୃତରେ ବିଫଳ ହୋଇଥିବା ପଥକୁ ଲୁଚାଇପାରେ।

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