[
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!!!!
Duplicating _$$_javassist_ classes after remote - call - OutOfMemory:
PermGen
-----------------------------------------------------------------------------
Key: EJBTHREE-736
URL:
http://jira.jboss.com/jira/browse/EJBTHREE-736
Project: EJB 3.0
Issue Type: Bug
Affects Versions: EJB 3.0 RC9 - FD
Environment: Linux Gentoo 2.6.18, JVM 1.5.0.08, 1.5.0.09, amd64
RedHat Linux EE 4.0. JVM 1.5.0.09, intel
Reporter: Piotr Tabor
Priority: Blocker
Attachments: leaktest.zip
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...
--
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