Phát 2: play.libs.WS VS Thư viện ứng dụng khách thứ ba để xử lý không đồng bộ

Question

Ứng dụng Java Play2 của tôi đang gọi một số dịch vụ web bên ngoài để nhận dữ liệu thông qua thư viện khách thứ ba đồng bộ. Đối với ứng dụng này tôi cần lưu lượng truy cập cao và khả năng mở rộng.

Các tài liệu vở kịch nói:

trường hợp khi mã của bạn có thể chặn bao gồm: Sử dụng API REST/WebService thông qua một thư viện bên thứ 3 khách hàng (tức là, không sử dụng Play không đồng bộ WS API) [ ...]

Lưu ý rằng bạn có thể bị cám dỗ vì vậy hãy bọc mã chặn của bạn trong tương lai. này không làm cho nó không chặn, nó chỉ có nghĩa là chặn sẽ xảy ra trong một chủ đề khác nhau [...]

Ngược lại, các loại sau đây của IO không chặn: Play WS API, ...

Trong ứng dụng Java Play2, không thực sự hữu ích khi sử dụng lời hứa để làm mọi thứ không đồng bộ vì hồ bơi mặc định được sử dụng cho công việc Futur. Kết quả là, việc sử dụng rất nhiều Futur sẽ dẫn đến kết quả giống như chỉ sử dụng các cuộc gọi đồng bộ với một nhóm luồng mặc định lớn: gần như cùng một số luồng trong cùng một nhóm.

Vì vậy, câu hỏi của tôi là:

• là API play.libs.WS trong API Java thực sự không đồng bộ (không chặn bất kỳ chủ đề trong hồ bơi mặc định chơi)?
• nên tôi luôn sử dụng thư viện thay vì thư viện khách hàng bên thứ 3 nếu muốn lưu lượng truy cập cao và khả năng mở rộng
• nhóm chủ đề được sử dụng bởi API play.libs.WS là gì và tôi có nên tăng kích thước không nếu ứng dụng của tôi thực hiện rất nhiều một cuộc gọi WS?
• có cách nào không đồng bộ với API play.libs.WS không, bằng cách bao gồm ứng dụng khách đồng bộ của bên thứ ba trong tương lai?

Thanks a lot

Loïc

Answer 1

Như Guillaume Bort nói trên danh sách chơi gửi thư, play.libs.WS API "có riêng của mình thread-pool, bởi thư viện AsyncHttp tự quản lý, nhưng vì nó sử dụng NIO dưới mui xe, nó không quan trọng vì nó thực sự không bị chặn. "

Vì vậy, nó nên được sử dụng thường xuyên nhất có thể.