Witam,
dziękuje za 'dobre słowo':)
Obejrzałem film nagrany na JUG (ze mną w roli głównej) - niestety nie
przeszedł mojej 'cenzury'.
Przyznam się, że prezentując nie przykładałem wagi do tego że mogę
zostać udostępniony szerszemu gronu (np. wyszukiwarce google).
(gdybym na to uważał prezentacja myślę byłaby inna - lub w ogóle by
się nie odbyła ;) )
Ogólnie - wydaje mi się, że nie było w niej dużo 'mięcha', raczej
wyrażanie moich generalnych opinii.
Poniżej załączam streszczenie, które myślę odda to (od strony
merytorycznej) co powiedziałem w ciągu 1h.
Pozdrawiam,
Mikołaj Grajek
-------
1. Po co NIO (część sieciowa):
- wlasne implementacje serwerów (np strumieniowanie filmu 3h+,
upload pliku 2Gb+)
- protokoły binarne (np. zgodność z istniejącymi, 'starymi'
systemami)
- Google Protocols ('międzysystemowy', wieloplatformowy,
elastyczny protokół optymalizowany z myślą o przesyłaniu danych
binarnych - ale nie tylko)
- wiele otwartych równoległych połączeń (rozwiązane przez
ServletApi 3.0)
2. Wady NIO w Javie:
- napisana analogicznie jak w C++ (szybka, 'niskopoziomowa'
implementacja, ale nie-obiektowo i nie-zdarzeniowo)
- dla niedoświadczonego (w NIO, i rzeczach związanych z
komunikacją) programisty to istne pole minowe (musi stworzyć
wielowątkowe, wydajne środowisko + uważać na techniczne aspekty
związane z warstwą obsługi sieci)
3. Grizzly
- to zestaw klas i narzędzi, które prawdopodobnie
'dobry'(doświadczony w takich rozwiązaniach) programista i tak
napisałby sam:
kolejki, potoki przetwarzania (np. przetworzenie requestu HTTP:
obebranie danych -> zebranie odpowiedniej ilości byte'ów potrzebnych
do odczytania ramki -> deflate -> połączenie 'chuncków' -> obsługa
HttpRequest),
pule wątków i kanałów
4. Wady grizzly:
- brak dokumentacji, kod niestety nadal dosyć niskopoziomowy
(trzeba poznać NIO, i jeszcze dodatkowo Grizzly'ego)
- dojrzały projekt, który już się nie rozwija - a programiści
zostali przeniesieni do innych zadań (lub odeszli)
- niewiele upraszcza, ale zapewnia, że nie wyłożymy się na jakimś
'kruczku' (przynajmniej przy tworzeniu wydajnej architektury), w
zamian za to, niestety, wprowadza nowe pułapki - przez braki w
dokumentacji i przykładach
5. Alternatywa: Netty (pod auspicjami JBoss)
- nowe, zunifikowane, obiektowo-zdarzeniowe API(zastąpienie np.
metody flip() z Buffer, własna abstrakcyjna klasa Channel która jest
'nad' java.nio.Channel i java.net.Socket)
- wspaniała dokumentacja (jak książka), przykłady, rysunki i
profesjonalne testy
- gratisowa implementacja Google Protocol Buffers (i wiele innych
narzędzi)
Jeśli ktoś ma zamiar kożystać z NIO (lub nawet pisać komunikację
własnymi protokołami np. za pomocą Socketów) - to jest to chyba
najlepszy wybór (dobrze udokumentowane, czytelne API + wg. testów -co
prawda ich testów- najszybszy framework dostępny na rynku). Ma bardzo
przystępny i porządny tutorial. Dlatego nie omawiałem specjalnie kodu
- bo ta dokumentacja na pewno zrobi to lepiej (kilka h/może jeden
dzień dla niedoświadczonego w tym temacie programisty).
6. Wnioski:
- do standartowej obsługi HTTP lepiej używać sprawdzonych
rozwiązań (np Jetty)
- Netty jest bardzo szybkie, ale nakład pracy chyba nie uzasadnia
wykorzystania (poza szczególnymi przypadkami opisanymi w 1.)
- jeśli ktoś potrzebuje, żeby jego program obsługiwał dziesiątki/
setki tyś. req. na sekundę to prawdopodobnie powinien zastanowić się
nad architekturą
(i np. sprzętowo rozdzielić ruch na wiele maszyn)