[ http://jira.jboss.com/jira/browse/EJBTHREE-736?page=all ] Piotr Tabor updated EJBTHREE-736: --------------------------------- Description: PermGen in EJB3 client aplication by remote interface. The application is as sample as it can be: -get remote interface of stateless EJB3 (by JNDI) - ask 1000 times to get a Collection (List) of 10 EntityBeans. After 255 there is OutOfMemory: PermGen. JVM options changes nothing (eventualy more PermSpace => longer run). The reason looks like the Javassist create lazyinitializer classes for every EntityBean retrived from the server. So: When I debug on server-side, I got before sending Entity to client: I got: myEntity[0].id=143534 myEntity[0].flow=<FlowEntity_$$_javassist_7> 13434 ... myEntity[0].user=<UserEntity_$$_javassist_15>... myEntity[0].stage=<StageEntity_$$_javassist_17>... And every remote call the class names (name)_$..._javassist_(index) got the same indexes (7,15,17) on server side (end every entity in returned collections of entities) But when I debug on client site - after return from remote call - the indexes of all returned entities are different (Each next increments index). So after first call I got: myEntity[0].id=143534 myEntity[0].flow=<FlowEntity_$$_javassist_0>... ... myEntity[0].user=<UserEntity_$$_javassist_1>... myEntity[0].stage=<StageEntity_$$_javassist_2>... ... myEntity[1].id=143534 myEntity[1].flow=<FlowEntity_$$_javassist_3> ... myEntity[1].user=<UserEntity_$$_javassist_4>... myEntity[1].stage=<StageEntity_$$_javassist_5>... ... After secund call: myEntity[0].id=143534 myEntity[0].flow=<FlowEntity_$$_javassist_6>... ... myEntity[0].user=<UserEntity_$$_javassist_7>... myEntity[0].stage=<StageEntity_$$_javassist_8>... ... myEntity[1].id=143534 myEntity[1].flow=<FlowEntity_$$_javassist_9> ... myEntity[1].user=<UserEntity_$$_javassist_10>... myEntity[1].stage=<StageEntity_$$_javassist_11>... ... And so on... ... and permGen after 260 iterations... I have not idea, how to deal with that... was: I got the same problem... PermGen in EJB3 client aplication by remote interface. The application is as sample as it can be: -get remote interface of stateless EJB3 (by JNDI) - ask 1000 times to get a Collection of 10 EntityBeans. After 255 there is OutOfMemory: PermGen. JVM options changes nothing (eventualy more PermSpace => longer run). The reason looks like the Javassist create lazyinitializer classes for every EntityBean retrived from the server. So: When I debug on server-side, I got before sending Entity to client: I got: myEntity[0].id=143534 myEntity[0].flow=<FlowEntity_$$_javassist_7> 13434 ... myEntity[0].user=<UserEntity_$$_javassist_15>... myEntity[0].stage=<StageEntity_$$_javassist_17>... And every remote call the class names (name)_$..._javassist_(index) got the same indexes (7,15,17) on server side (end every entity in returned collections of entities) But when I debug on client site - after return from remote call - the indexes of all returned entities are different (Each next increments index). So after first call I got: myEntity[0].id=143534 myEntity[0].flow=<FlowEntity_$$_javassist_0>... ... myEntity[0].user=<UserEntity_$$_javassist_1>... myEntity[0].stage=<StageEntity_$$_javassist_2>... ... myEntity[1].id=143534 myEntity[1].flow=<FlowEntity_$$_javassist_3> ... myEntity[1].user=<UserEntity_$$_javassist_4>... myEntity[1].stage=<StageEntity_$$_javassist_5>... ... After secund call: myEntity[0].id=143534 myEntity[0].flow=<FlowEntity_$$_javassist_6>... ... myEntity[0].user=<UserEntity_$$_javassist_7>... myEntity[0].stage=<StageEntity_$$_javassist_8>... ... myEntity[1].id=143534 myEntity[1].flow=<FlowEntity_$$_javassist_9> ... myEntity[1].user=<UserEntity_$$_javassist_10>... myEntity[1].stage=<StageEntity_$$_javassist_11>... ... And so on... ... and permGen after 260 iterations... I have not idea, how to deal with that... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/EJBTHREE-736?page=all ] Piotr Tabor updated EJBTHREE-736: --------------------------------- Priority: Blocker (was: Major) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/EJBTHREE-736?page=comments#action_12345052 ] Piotr Tabor commented on EJBTHREE-736: -------------------------------------- On MS WindowsXP the bug doesn't cause OutOfMemoryException: Permgen - but application hungs after 2000 iterations (on database with 6 books) - and client consume all CPU (probably on generating _javassist classes) and all free memory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/EJBTHREE-736?page=comments#action_12345939 ] Carsten Wolters commented on EJBTHREE-736: ------------------------------------------ I have the same problem. It occures when passing a detached entity with a relation into a remote call. It looks as if the javaassist-proxy-classes for the relations are generated each time and are not freed, so the perm space is will be full after some thound calls. // permgen space test with detached entity containing lazy javaassist proxies: (crashes jboss 4.0.5GA around iteration ~1430) for(int i = 0; i < 2000; ++i) { remoteEJB3Bean.touch(detachedEntityWithLazyRelation); System.out.println("touched: " + i + " times"); } This is a real blocker, because we cannot use detached entities as data transfer objects on remote calls!!!! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/EJBTHREE-736?page=all ] Carlo de Wolf resolved EJBTHREE-736. ------------------------------------ Fix Version/s: EJB 3.0 RC10 - FD Resolution: Done Upgrade to javassist 3.4 fixes this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/EJBTHREE-736?page=comments#action_12355384 ] d k commented on EJBTHREE-736: ------------------------------ I wonder why loading eager solves the problem? Shouldn't it make it worse? I mean, eager load fetches more data from the database in the memory. Why switching from lazy to eage fixes this? If the bean was not stateless maybe could make some sense ... Is it hte reason that the relation is many-to-one and if so should we enable eager fetch for all relations that are many to one? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira