proxy പ്രാമാണീകരണ വീണ്ടും ശ്രമങ്ങൾക്കായി Jersey 2 അപ്‌ലോഡ് ബഫർ ചെയ്യുന്നു

പ്രാമാണീകരണ ചർച്ചകൾക്ക് അപ്‌ലോഡ് വീണ്ടും അയക്കേണ്ടിവരുമ്പോൾ Jersey 2 Apache connector-ന്റെ അഭ്യർത്ഥന എന്റിറ്റി ആവർത്തനീയമാക്കുക.

proxy വെല്ലുവിളിയ്ക്ക് ശേഷം വീണ്ടും ശ്രമിക്കുന്ന അപ്‌ലോഡിന് അതിന്റെ ബോഡി വീണ്ടും വേണം. Jersey 2-ന്റെ Apache connector-ന്, ആ ക്ലയന്റ് നിർമ്മിക്കാൻ ഉപയോഗിക്കുന്ന കോൺഫിഗറേഷനിൽ ബഫർ ചെയ്ത എന്റിറ്റി പ്രോസസ്സിംഗ് തിരഞ്ഞെടുക്കുക:

ClientConfig config = new ClientConfig();
config.connectorProvider(new ApacheConnectorProvider());
config.property(ClientProperties.PROXY_URI,
                "http://proxy.example.net:8080");
config.property(ClientProperties.REQUEST_ENTITY_PROCESSING,
                RequestEntityProcessing.BUFFERED);

ലഭ്യമായ ക്ലയന്റിലൂടെ അപ്‌ലോഡ് നടത്തുക. ഈ തരങ്ങൾ Jersey client, Apache-connector പാക്കേജുകളിൽ നിന്നാണ്; ഉപയോഗിക്കാത്ത കോൺഫിഗറേഷൻ സെറ്റ് ചെയ്യുന്നത് അഭ്യർത്ഥനയെ ബാധിക്കില്ലായിരുന്നു.

connector ബഫർ ചെയ്ത എന്റിറ്റിയെ Apache-യുടെ BufferedHttpEntity-ൽ പൊതിയുന്നു. ബഫർ ചെയ്യാത്ത സ്ട്രീമിംഗ് എന്റിറ്റി ആവർത്തനീയമല്ല. ബഫറിംഗ് ഉപയോഗിച്ച ഉൽപാദകനെ വീണ്ടും വായിക്കുന്നതിനു പകരം പ്രാമാണീകരണ പ്രവാഹത്തിന് വീണ്ടും അയക്കാവുന്ന ബൈറ്റുകൾ നൽകുന്നു.

ഒരു 407-ന് ശേഷം പ്രാമാണീകരണം അവസാനിക്കുമെന്ന് ഇത് ഉറപ്പുനൽകുന്നില്ല. ചില സ്കീമുകൾക്ക് ന്യായമായി നിരവധി കൈമാറ്റങ്ങൾ ആവശ്യമാണ്, അതിനാൽ മറ്റൊരു വെല്ലുവിളിയെ നഷ്ടപ്പെട്ട അവസ്ഥയായി കാണുന്നതിന് മുമ്പ് മുഴുവൻ ചർച്ചയും പരിശോധിക്കുക.

ബോഡി വലിപ്പം മെമ്മറി ബജറ്റിനുള്ളിൽ നിർത്തുക. വലിയ സ്ട്രീമിംഗ് അപ്‌ലോഡിന് ആ ജോലിഭാരത്തിന് അനുയോജ്യമായ വീണ്ടും അയക്കൽ തന്ത്രം വേണം; എല്ലാ അഭ്യർത്ഥനയ്ക്കും ബഫറിംഗ് പ്രവർത്തനക്ഷമമാക്കുന്നത് ചർച്ചയുടെ പരാജയം മെമ്മറി തീരുന്നതിലേക്ക് മാറ്റിയേക്കാം.

അനുബന്ധ ലേഖനങ്ങൾ