WrASSE #3 - po spotkaniu
Przemyslaw Pokrywka
Dziękuję wszystkim przybyłym za obecność i ciekawą dyskusję.
Zwłaszcza wnioski z dyskusji utwierdziły mnie w przekonaniu, że jeśli
w danym przypadku nie korzysta się z nested react a dostęp do stanu
obiektu możemy łatwo zsynchronizować za pomocą tradycyjnych metod, to
aktorów lepiej nie stosować.
W tych przypadkach, w których nested react pozwala na uproszczenie
kodu względem alternatyw (np. wzorca stanu), lub istotne jest
zagwarantowanie pełnej synchronizacji dostępu do stanu konkretnego
obiektu, użycie aktorów warto rozważyć.
Zapraszam do podzielenia się swoimi własnymi wnioskami ntt. -
uzupełnienia ( / podważenia?) moich. Zastanawiam się nad tym, czy nie
zebrać by wniosków z naszego spotkania w jakiś post na blogu po
angielsku, aby podzielić się tym (i wyeksponować na potencjalną
krytykę) z resztą Scala community. Odnoszę wrażenie, że w sieci
tematowi aktorów towarzyszy sporo szumu, który warto rozwiewać, aby
wskazywać na realne korzyści wynikające z użycia aktorów oraz unikać
stosowania ich w miejscach, gdzie bardziej nadawałyby się inne
podejścia.
Pozdrawiam!
Przemek
Łukasz Kuczera
Niestety implementacja w Scali utyka, są problemy z wyciekami pamięci. Twitter odszedł od aktorów, a w Lifcie jest własna implementacja + warstwa abstrakcji (można wpiąć np. Akka). Ostatecznie jednak dobrze że są w podstawowej bibliotece są łatwo dostępni dzięki temu.
--
Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie "WrASSE".
Aby zamieszczać posty w tej grupie, wyślij e-mail na adres wroclaw-scal...@googlegroups.com.
Aby anulować subskrypcję tej grupy, wyślij e-mail na adres wroclaw-scala-enth...@googlegroups.com.
Aby uzyskać więcej informacji, odwiedź tę grupę pod adresem http://groups.google.com/group/wroclaw-scala-enthusiasts?hl=pl.
Paweł Badeński
2010/11/10 Łukasz Kuczera <l.ku...@jextreme.pl>:
--
Paweł Badeński
Kraków, Poland
Łukasz Kuczera
Możliwe że Scalowe też już nie mają nie śledzę developmentu na bieżąco ;)
Przemyslaw Pokrywka
łatwymi do przerabiania na zdalne.
Co do wycieków pamięci, to najlepiej by przywołać konkretny przykład.
W naszym projekcie użyliśmy aktorów ze Scali 2.7.7, a więc znacznie
bardziej zabugowanych, niż w wersji 2.8 a do tego tworzymy bardzo
wiele instancji aktorów (aktor per request przy dziesiątkach requestów
na sekundę). Teoretycznie przy rozmiarze obsługiwanego ruchu
powinniśmy szybko zostać dotknięci błędami OutOfMemory, w praktyce
jednak takiego nie napotkaliśmy ani razu. Jak do tej pory ani razu nie
byliśmy zmuszeni do zrestartowania aplikacji z powodu wyczerpania
pamięci - system działa produkcyjnie od czerwca.
Mieliśmy tylko jedną niespodziankę na etapie developmentu, kiedy
okazało się, że liczba wystartowanych wątków na jvm wraz z generowanym
ruchem rosła bez żadnego ograniczenia (przy w miarę stałej liczbie
wątków jednocześnie aktywnych). Okazało się, że jest to cecha
frameworku aktorów, który zamyka pulę wątków w momencie, gdy kończy
się działanie ostatniego aktora. Przy nowym requeście pula inicjowana
była na nowo, stąd liczba startowanych wątków szła w górę bez końca.
Obeszliśmy problem powołując do życia dodatkowego aktora "figuranta",
który nie robił nic, poza tym, żeby ze względu na niego framework nie
zamykał puli. Później dowiedziałem się, że nie tylko nas zaskoczyła ta
cecha frameworku.
Pozdrawiam
W dniu 10 listopada 2010 16:20 użytkownik Łukasz Kuczera
<l.ku...@jextreme.pl> napisał: