[jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-736) Duplicating _$$_javassist_ classes after remote - call - OutOfMemory: PermGen

d k (JIRA) jira-events at lists.jboss.org
Wed Mar 7 17:57:35 EST 2007


    [ 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

        



More information about the jboss-jira mailing list