starback napisał(a)
Mam podobny problem z serwerem GlassFish + Eclipse. Po kilkunastu redeployach aplikacji pojawia się błąd. Muszę wtedy ubić proces serwera w managerze zadań i ponownie uruchomić serwer. Zauważyłem też, że każdy deploy aplikacji trwa co raz dłużej. Zna ktoś rozwiązanie tego problemu?
Ja troche profilowalem ten problem w GlassFish (nie zwiazany z Eclipse, nie uzywam tej integracji, mamy standalone GF i JRebel, ale nasz serwer ciaglej integracji robi deploy kilka razy dziennie za pomoca mavena). Z tego co widzialem to jest memory leak GF: jak robisz deploy, startuje jakis watek ktory trzyma referencje do WebAppClassLoader, ktory z kolei trzyma wsystkie klasy aplikacji. Jak robisz undeploy, ten watek nie jest zabijany, ale trwa w najlepsze dalej. Po 10 redeployu masz juz 10 takich watkow, kazdy trzyma classloader ktory z kolei trzyma wszystkie klasy zaladowane podczas uzycia tej aplikacji. Po ktoryms razie (zaleznie od ustawienia Perm) po prostu kleka.
Wniosek - sprawdz Twoja aplikacje (polecam YourKit Profiler, droga bestia, ale wersja eval ma chyba 15 dni a problem zidentyfikujesz w pol dnia), i usun Twoje leaki. Zwieksz PermSpace. Nie rob tak czest redeployow (wylacz ten redeployment w eclipse, i zapoznaj sie z JRebel, piekne narzedzie, taki jakby super madry classloader ktory sam przeladowuje klasy bez redeployow aplikacji*). Naucz sie zyc z GlassFish i jego wadami :( ...
- Moj dzien wyglad tak, ze rano biore nowe zrodla (lub nie, zalezy ;d), buduje, robie deploy, i tyle. Zmieniam kod, a JRebel sam odkrywa ze zmienilem klasy i je przeladowuje, nie musze nic redeployowac. JRebel rowniez potrzebuje troche wiecej PermGen, ale jest to zdecydowany krok naprzod. JRebel dziala rowniez z tomcatem, i tam to juz bajka - PermSpace nie widzialem od dlugiego czasu.