cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Permgen, permgen
Date Sun, 21 Nov 2010 15:53:40 GMT
Now you've made the mistake of showing some interest in this :-)

Consider this line from the yourkit trace.

"#6666","2:34.164","main","WSDLManagerImpl.loadDefinition","sun.reflect.GeneratedConstructorAccessor65","loaded"

Someone has done something reflective that creates a class, and that
class sticks around.

I suspect that the WSDLFactory is the culprit here. Got any ideas for
how to force it into the context class loader?


On Sun, Nov 21, 2010 at 10:34 AM,  <dkulp@apache.org> wrote:
>
>
> On Nov 21, 2010, at 9:43 AM, Benson Margulies <bimargulies@gmail.com> wrote:
>
>> I see two apparent sinks of permgen in our build from yourkit.
>>
>> One is the XSD-to-Java mojo, which doesn't belong to us. But we might
>> be able to wrap it in such a way as to change its behavior.



>
> Or just use the cxf-xjc-plugin that we do have control over.
>
> Dan
>
>
>
>>
>> The other is the SOAPBindingUtil.getProxy. The proxy classes, which
>> co-locate in the class loader of the classes they proxy, never go
>> away.
>>
>> So, they end up in the per-plugin class loader, which isn't going to
>> go away for the life of the build.
>>
>> So, it looks like we need an additional classloader in the path here
>> that can be GC'd.
>>
>> The WSDL2Java mojo is the top of this.
>>
>> Question: should SOAPBindingUtil just use the thread context class
>> loader, which would allow us to easily deal with this in the mojo,
>> instead of sticking the proxies into the same class loader as the
>> things proxied?
>>
>> I think so.
>
>

Mime
View raw message