Odtwórz 2: play.libs.WS VS Biblioteka klienta innej firmy do asynchronicznego przetwarzania

Question

Moja aplikacja Java Play2 wywołuje niektóre zewnętrzne usługi internetowe, aby uzyskać dane przez synchroniczną bibliotekę klienta innej firmy. Do tej aplikacji potrzebuję dużego ruchu i skalowalności.

Dokumentacja zabaw mówi:

przypadkach, gdy kod może blokować obejmują: Korzystanie API REST/Zestawienie poprzez biblioteki 3rd party klienta (czyli nie Korzystanie Play asynchronicznego WS API) [ ...]

Pamiętaj, że możesz ulec pokusie, aby zawinąć swój kod blokujący w kontraktach futures. to nie sprawia, że ​​nie blokuje, to po prostu oznacza, że ​​blokowanie nastąpi w innym wątku [...]

Natomiast następujące rodzaje IO nie blokują: Play WS API, ...

W aplikacji Play2 Java nie jest naprawdę użyteczne stosowanie obietnic, aby uczynić rzeczy asynchronicznymi, ponieważ domyślna pula odtwarzania jest używana do zadań Futur. W rezultacie użycie dużej ilości Futur będzie skutkowało tym samym, co używanie tylko wywołań synchronicznych z dużą domyślną pulą wątków: mniej więcej tyle samo wątków w tej samej puli.

Więc moje pytania to:

• jest API play.libs.WS w Java API naprawdę asynchroniczny (nie blokuje żadnego wątku w domyślnej puli Play)?
• czy powinienem zawsze używać go zamiast mojej trzeciej biblioteki klienta, jeśli chcę duży ruch i skalowalność?
• jaka jest pula wątków używana przez API play.libs.WS i czy powinienem zwiększyć jej rozmiar, jeśli moja aplikacja dużo zrobi połączenia WS?
• jest sposób na asynchronizację z API play.libs.WS, poprzez zawinięcie klienta synchronicznego innej firmy w kontraktach futures?

Thanks a lot

Loïc

Answer 1

Jak powiedział Guillaume Bort na liście mailingowej play, play.libs.WS API „ma swój własny wątek basen, zarządzanych przez bibliotekę samego AsyncHttp, ale ponieważ używa NIO pod maską, nie ma to znaczenia, ponieważ zasadniczo nie jest blokująca. "

Powinny być używane tak często, jak to możliwe.