Jakiś czas temu w swojej aplikacji postanowiłem że użyję biblioteki Celerity, co niejako zmusiło mnie do postawienia JRuby’ego. Wszystko pięknie było dopóki nie testowałem zadań w tle, bo okazało się że Workling pod JRuby nie działa, a co więcej większość pluginów do background tasków w ogóle nie działa pod JRuby’m. Przeczytałem internet na jednej stronie znalazłem jedno zdanie mówiące o tym, że można użyć backgroundJob pod JRuby korzystając z gema bjj. Za żadne skarby nie mogę sobie z tym poradzić. Czy ktoś miał podobny problem? Testowałem również instalację samego BJ (a może się uda), ale wywala się na tworzeniu migracji. Podejrzewam, że problem jest podobny jak w przypadku worklinga który nie chciał się uruchomić ponieważ zgłaszał brak adaptera postgresa (bo tutaj zwykły ruby korzysta z innego adaptera niż jruby). Adapter postgresa mam lda jruby i działa.
Znowu 4:00 i znowu kilka godzin siedzenia i sprawdzania co było źle. Okazało się, że pod nosem miałem podpowiedź. Trzeba było uruchomić worklinga tak:
jruby -X+O script/workling_client run
i poszło. Co ciekawe jak odpalałem worklinga z innymi parametrami to oczywiście mi napisał w pierwszej linijce, że trzeba go odpalić z parametrami -X+O tylko najpierw musiałem skopiować błąd i szukać w googlu zamiast spróbować innych parametrów (co kosztowało jakieś 8h pracy).
Dzięki za pomoc.
Btw. Jak czytałem o innych serwerach kolejkowania to niektóre z nich miały tak dość fajnie zorganizowane monitorowanie zadań w kolejce na tabeli w bazie danych. Próbowałem znaleźć jakieś info czy starling tak potrafi, ale nic nie znalazłem. Doszedłem do wniosku, że sam sobie napiszę takie pseudo monitorowanie, ale może jakoś to można zrobić inaczej. Orientujecie się może czy Starling umożliwia takie monitorowanie zadań, żeby można było sprawdzić co jest w kolejce, co jest przetwarzane itp. z poziomu aplikacji?
Straszą rzecz przeczytałem. JRuby podobno nie wspiera fork’a, a tym samym nie można odpalić Worklinga w trybie demona. Wyskakuje error ‘fork is unsafe and disabled by default on JRuby (NotImplementedError)’. Próbowałem odpalić komendą
WARNING: fork is highly unlikely to be safe or stable on the JVM. Have fun!
i niby się uruchamia, ale podczas testów mi to nie działało. Jest na to jakieś rozwiązanie? W ogóle w swojej aplikacji docelowo muszę uruchomić kilka instancji worklinga. Workling korzysta w swoich metodach z celerity przez co musi on byc uruchomiony przez jruby.
proszę o pomoc
pozdrawiam
Jeszcze znalazłem gdzieś informacje że coś takiego jak JRuby + JMS/ActiveMQ może działać jak kolejka background job’ów. Czy znacie może takie rozwiązanie?
Bałem się tego trochę, bo wydawało mi się, że to trochę naokoło.
Bardzo dużo czasu spędziłem właśnie na znalezieniu czegoś co działało by pod JRuby. Za każdym razem problemem był tryb demona w którym uruchamiało się serwer kolejki. W moim przypadku muszę odpalić kilka instancji kolejek więc tym bardziej był problem. Szukanie się jednak opłaciło. Wczoraj znalazłem a dzisiaj zaimplementowałem i działa. ActiveMQ + Stopm + ActiveMessaging w implementacji bardzo jest podobny do Worklinga, działa w 100% pod JRuby, umożliwia odpalanie wielu kolejek a do tego posiada panel admina! Wrażenie miałem takie jak by to chodziło nawet szybciej od Worklinga ze Starlingiem. Naprawdę ciekawe rozwiązanie. Jak ktoś szuka serwera do background taksów to jestem pewien, że lepszego (a przynajmniej łatwiejszego w implementacji, który by działał) się nie znajdzie. Poza tym jest dość dobra dokumentacja i kilka dobrych przykładów użycia. Linki:
Dazz, szacun za risercz! Ponieważ problem MQ prześladuje mnie od początku mojej pracy zawodowej z rails i nie popuszcza, pogrzebię trochę w podanych przez Ciebie zasobach. W ActiveMQ trochę mnie przeraża rozmach rozwiązania (ilość wspieranych języków i protokołów), ale wsparcie dla AMQP = WIN.
A nie myślałeś o RabbitMQ? Jeden z lżejszych i bardziej polecanych providerów (serwerów) AMQP.
Co rozumiesz przez “panel admina”? Jakieś monitorowanie, podgląd zawartości kolejek? Ostatnio szukałem czegoś do RabbitMQ, ale nie znalazłem nic co można by określić jako panel admina.
Zacząłem to instalować w desperackiej próbie znalezienia czegoś co będzie działać. Ale później zrezygnowałem.
Tak w ogóle to chciałem nieco sprostować poprzedni post, bo się trochę pośpieszyłem z wychwalaniem ActiveMessaging. Otóż ActiveMQ działa w trybie demona pod JRuby bez problemu, ale poller który sie uruchamia aby kolejka zaczęła “iść”, to już niebardzo (ten sam błąd z fork’iem co w innych przypadkach). Bolało trochę jak to zobaczyłem, ale odpaliliśmy z ‘&’ na końcu i na razie tak zostawiam. Muszę teraz poczytać dokumentację co potrafi MQ bo rzeczywiscie sporo tego jest.
Panelu admina w MQ jeszcze do konca nie rozpracowałem, ale informacje jakie tam są to m.in.:
Bałem się tego trochę, bo wydawało mi się, że to trochę naokoło.[/quote]
Trochę naokoło, ale do testów aplikacji w ruby używałem przez kilka miesięcy i działa (prawie) bez zarzutów. Problemy są tylko z niektórymi metodami, które dostają bloki (jest to związane z implememtacją, a konkretniej komunikacją między procesami jruby i ruby).
Wiesz co… zacząłem się tym bawić i uruchomiłem normalnie i działa. Znajduje mi na przykład linki na stronie ale za nic nie mogę wydobyć na przykład atrybutu “href” ze znalezionego linku. Czy też miałeś taki problem?
Dziękuję… teraz już działa… Korzystałem z tej strony jak pisałem w zwykłym celerity, ale tam używałem po prostu link.href i wszystko. Teraz przy culerity ten sposób nie działał, ale nie wpadłem na to żeby przejrzeć tę stronę dokładniej No nic. Człowiek się uczy na błędach… Jeszcze raz dzięki za podpowiedź. pozdrawiam
Aplikacja w której wykorzystuję Celerity to dość złożony robot internetowy który przeszukuje wiele stron i wyszukuje w nich wielu danych. Napisałem ją na trzy sposoby:
bez użycia celerity (Mechanize+Hpricot) - działało idealnie
z użyciem celerity
z użyciem culerity
Ponieważ nie chciałem zrezygnować z celerity/culerity, pojawił mi się bardzo wielki problem wydajnościowy. Java którą odpala JRuby zjada takie zasoby że server VPS który posiada 512 MB Ramu i 1GB pliku stronicowania nie daje rady. Załamałem ręce. Ogólnie odpalam tak:
glassfish (po odpaleniu łącznie server je 276 ramu)
activemq (łącznie 374 ramu)
Zostaje 138 ramu na pollera activemessaging, który właściwie wykonuje całą robote, bo robot działa w zadaniach w tle.
Po odpaleniu pollera i po uruchomieniu akcji robota glassfish wisi (po 2 minutach server odpowiada na żądanie), ram cały zjedzony, plik prawie na maxa.
top pokazuje kilka procesów javy pożerających pamięć. Już prawie jestem zdecydowany na powrót do pierwszej wersji aplikacji (ktora nie obsluguje stron z javascript). Macie może jakiś pomysł? Cokolwiek?
No nic. Człowiek się uczy na błędach… Jeszcze raz dzięki za podpowiedź. pozdrawiam