ຄຳຮ້ອງ Java ພ້ອມກັນອາດແບ່ງປັນການຕັ້ງຄ່າພຣັອກຊີທີ່ຜິດ
ເບິ່ງວ່າເປັນຫຍັງການປ່ຽນຄຸນສົມບັດທົ່ວໂລກຕໍ່ຄຳຮ້ອງຈຶ່ງຮົ່ວຂ້າມ thread ແລະວິທີເກັບນະໂຍບາຍພຣັອກຊີໄວ້ທີ່ client.
thread ໜຶ່ງຕັ້ງຄຸນສົມບັດພຣັອກຊີ, ສົ່ງຄຳຮ້ອງ, ແລ້ວຟື້ນຟູຄ່າເກົ່າ. thread ອີກອັນໜຶ່ງເຮັດແບບດຽວກັນກັບພຣັອກຊີອື່ນ. ເມື່ອອ່ານຈາກເທິງລົງລຸ່ມ ລະຫັດເບິ່ງຮຽບຮ້ອຍ ແຕ່ thread ທັງສອງກຳລັງປ່ຽນສະຖານະ JVM ທີ່ແບ່ງປັນ.
System.setProperty() ປ່ຽນຄຸນສົມບັດລະບົບຂອງຂະບວນການ. ມັນບໍ່ໄດ້ຜູກເສັ້ນທາງໃສ່ thread ທີ່ເອີ້ນມັນ. ຄຳຮ້ອງພ້ອມກັນອາດເຫັນຄ່າທີ່ຂຽນໄວ້ສຳລັບວຽກຂອງຄົນອື່ນ ແລະ client ທີ່ມີຢູ່ແລ້ວອາດໄດ້ຈັບການຕັ້ງຄ່າຂອງຕົນເອງໄປແລ້ວ.
ເຮັດໃຫ້ເສັ້ນທາງເປັນສ່ວນໜຶ່ງຂອງ client
ສຳລັບ HTTP client ຂອງ Java ໃຫ້ສ້າງ client ດ້ວຍ ຕົວເລືອກພຣັອກຊີທີ່ຕັ້ງໃຈ. ເກັບ client ແຍກຕ່າງຫາກ ເມື່ອວຽກຕ້ອງການນະໂຍບາຍເສັ້ນທາງຕ່າງກັນ:
HttpClient client = HttpClient.newBuilder()
.proxy(ProxySelector.of(
new InetSocketAddress("203.0.113.10", 8080)))
.connectTimeout(Duration.ofSeconds(5))
.build();ການນຳເຂົ້າແມ່ນ java.net, java.net.http ແລະ java.time. ທີ່ຢູ່ນີ້ເປັນຕົວຢ່າງ; ສຳລັບການທົດສອບເສັ້ນທາງສາທາລະນະທີ່ໄດ້ຮັບອະນຸຍາດ ບັນຊີພຣັອກຊີ HTTP ໃຫ້ຈຸດປາຍທາງທີ່ເປັນຕົວແທນ. ຕັ້ງຄ່າກຳນົດເວລາຄຳຮ້ອງ ແລະ ການຢືນຢັນຕົວຕົນພຣັອກຊີ ແຍກຕ່າງຫາກຕາມຄວາມຕ້ອງການຂອງແອັບ.
ວິທີ proxy ຂອງ builder ບັນທຶກການເລືອກລະດັບ client. ສິ່ງນັ້ນເຮັດໃຫ້ນະໂຍບາຍກວດສອບໄດ້ງ່າຍກວ່າລຳດັບການຂຽນທົ່ວໂລກທີ່ຫຸ້ມການດຳເນີນການແບບອະສິງໂຄຣນັດ.
ການຕັ້ງຄ່າທົ່ວໂລກຍັງມີປະໂຫຍດ
ນະໂຍບາຍພຣັອກຊີດຽວທົ່ວ JVM ອາດເໝາະສົມ ເມື່ອ client ທຸກອັນທີ່ເຂົ້າຮ່ວມຖືກຕັ້ງໃຈໃຫ້ປະຕິບັດຕາມ. ຕັ້ງນະໂຍບາຍນັ້ນຕອນເລີ່ມແອັບ ແລະກວດສອບວ່າຫ້ອງສະໝຸດໃດເຄົາລົບມັນ.
ບັນຫາເກີດຂຶ້ນເມື່ອຄຸນສົມບັດທົ່ວໂລກຖືກໃຊ້ເປັນສະວິດຊົ່ວຄາວສຳລັບຄຳຮ້ອງແຕ່ລະອັນ. ໃນເຊີບເວີ ຜູ້ຮັບໃຊ້ພື້ນຫຼັງ ແລະການເອີ້ນຫ້ອງສະໝຸດອາດແລ່ນພ້ອມກັນ ເຖິງແມ່ນວິທີຂອງທ່ານເບິ່ງຄືຊິງໂຄຣນັດ. ເກັບສະຖານະເສັ້ນທາງໄວ້ກັບ client ຫຼື connector ທີ່ເປັນເຈົ້າຂອງການເຊື່ອມຕໍ່ ເພື່ອບໍ່ໃຫ້ຄຳຮ້ອງອື່ນປ່ຽນມັນກາງວຽກ.