Dzięki za odpowiedź.
Owszem, aplikacja jest niezle spaprana w kwestii JPA: zostalo tam ustawione RESOURCE_LOCAL i nie ma obslugi transakcji przez kontener (przez poprzednich programistow, my to rozwiajmy dalej). Nie udalo sie tego sensownie zrefaktoryzowac, ale nie ma tam transakcji rozproszonych, wiec az tak nie boli. Ja oddzidziczylem ta aplikacje, zrefaktoryzowalem i podnioslem z JEE 5.0 do 7.0. W tej chwili jest juz lepiej, ale musze pracowac ze starym kodem z duza iloscia WTFow. Ale za kazdym razem EntityManagery tworzone z fabryk sa zamykane, wiec leaka w JPA byc nie powinno.
To się dzieje wtedy, gdy idzie dużo deployów w krótkim czasie. Po pojedynczym deployu jest spoko. Projekt jest dosyć duży, miliona linii kodu nie ma, ale w przyszłości na pewno będzie. Jest to około 80 tabel w SQL. Nigdy nie było tak, aby wysypało mi się po pierwszym, ale po kilku krótkich owszem, zdarza się to często. Wychodzi na to, że szybkie deploye dużego projektu zabijają classloader. Dlaczego tak się dzieje, skoro deploy wykonuje undeploy, który powienien wyczyścić? Jak szukać tego leaka, z użyciem darmowych narzędzi?
Nie używam bibliotek, o których wspomniałeś. Za to JPA, IceFaces 1.8 (stary projekt), JSF 2.2, Spring Security i JasperReports i pare innych bibliotek.
http://stackoverflow.com/questions/7683434/permgen-space-error-glassfish-servero,
Z tego co widzę użytkownicy GlassFisha często tego doświadczają:
https://java.net/jira/browse/GLASSFISH-20732
Czy możliwe, że to defekt serwera aplikacji?
Jak najprościej szukać leaków?