ການບັຟເຟີການອັບໂຫຼດ Jersey 2 ສຳລັບການລອງຢືນຢັນຜ່ານ proxy ຄືນ

ເຮັດໃຫ້ entity ຄຳຮ້ອງ Jersey 2 ກັບ Apache connector ສາມາດເຮັດຄືນໄດ້ ເມື່ອການເຈລະຈາຢືນຢັນຕ້ອງສົ່ງການອັບໂຫຼດຄືນ.

ການອັບໂຫຼດທີ່ລອງຄືນຫຼັງການທ້າທາຍຈາກ proxy ຕ້ອງການຕົວຂອງມັນອີກ. ສຳລັບ Apache connector ຂອງ Jersey 2, ເລືອກການປະມວນຜົນ entity ແບບບັຟເຟີໃນການຕັ້ງຄ່າທີ່ໃຊ້ສ້າງ client ນັ້ນ:

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);

ດຳເນີນການອັບໂຫຼດຜ່ານ client ທີ່ໄດ້ມາ. ປະເພດເຫຼົ່ານີ້ມາຈາກແພັກເກດ Jersey client ແລະ Apache-connector; ການຕັ້ງຄ່າທີ່ບໍ່ໄດ້ໃຊ້ຈະບໍ່ກະທົບຕໍ່ຄຳຮ້ອງ.

connector ຫໍ່ entity ແບບບັຟເຟີໃນ BufferedHttpEntity ຂອງ Apache. entity ແບບ streaming ທີ່ບໍ່ໄດ້ບັຟເຟີຂອງມັນເຮັດຄືນບໍ່ໄດ້. ການບັຟເຟີໃຫ້ byte ແກ່ຂະບວນການຢືນຢັນທີ່ສາມາດສົ່ງຄືນໄດ້ ແທນການອ່ານ producer ທີ່ຖືກໃຊ້ໄປແລ້ວຄືນ.

ມັນບໍ່ຮັບປະກັນວ່າການຢືນຢັນຈະສິ້ນສຸດຫຼັງ 407 ດຽວ. ບາງຮູບແບບຕ້ອງການຫຼາຍການແລກປ່ຽນຢ່າງຖືກຕ້ອງຕາມກົດ, ດັ່ງນັ້ນກວດເບິ່ງການເຈລະຈາທັງໝົດກ່ອນຈະຖືວ່າການທ້າທາຍອື່ນເປັນສະຖານະທີ່ສູນເສຍ.

ຮັກສາຂະໜາດຕົວໃຫ້ຢູ່ໃນງົບປະມານຄວາມຈຳ. ການອັບໂຫຼດແບບ streaming ຂະໜາດໃຫຍ່ຕ້ອງການ ຍຸດທະສາດການຫຼິ້ນຄືນທີ່ເໝາະກັບພາລະນັ້ນ; ການເປີດບັຟເຟີສຳລັບທຸກຄຳຮ້ອງອາດປ່ຽນຄວາມລົ້ມເຫລວຂອງການເຈລະຈາເປັນຄວາມຈຳໝົດ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ