[
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?
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
Fix For: AS 4.2.0 CR1
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