Hi Sergey, sure, I'll apply the changes to our development Tomee server and see how it behaves. I'll probably won't get around to do that until tomorrow, so I might have some results back next week.
I'll keep you posted. Thanks On 26 June 2014 18:09, Sergey Beryozkin <[email protected]> wrote: > Hi > > On 26/06/14 19:12, [email protected] wrote: > >> Thanks for following this up Sergey. I haven't dig much into the code, but >> from what I see, this is the part of the code where the proxy map is being >> created (AbstractResourceInfo#getProxyMap): >> >> >> private <T> Map<Class<?>, Map<T, ThreadLocalProxy<?>>> >>> getProxyMap(Class<T> keyCls, String prop, boolean create) { >>> Object property = null; >>> synchronized (bus) { >>> property = bus.getProperty(prop); >>> if (property == null && create) { >>> Map<Class<?>, Map<T, ThreadLocalProxy<?>>> map >>> = new ConcurrentHashMap<Class<?>, Map<T, >>> ThreadLocalProxy<?>>>(2); >>> bus.setProperty(prop, map); >>> property = map; >>> } >>> } >>> return (Map<Class<?>, Map<T, ThreadLocalProxy<?>>>)property; >>> } >>> >> >> >> Do you really need a ConcurrentHashMap here? If not, it can be replaced >> with a WeakHashMap and that should solve this particular issue. You can >> also try and wrap a WeakHashMap with Collections.synchronizedMap, but that >> might impact performance if there's much contention. >> >> This was of good help, thanks. It might do a trick hopefully it will. > We have ProviderFactory linking to providers stored on Endpoint, so > getting the endpoint collected will ensure the custom provider classes will > get unloaded. > > I've committed the update, For now I'll keep the change on the trunk only > for a bit to ensure it has no side-effects and then push down to 2.7.x and > 2.6.x before they get released. > > > Let me know if I can be of any help. >> > > > If you could possibly rebuild 2.6.x (mvn install -Pfastinstall) with > replacing all of ConcurrentHashMap with synhronized wrappers of WeakHashMap > and see if it actually solves the issue in Tomee in the next few days or > next week then it would help. The fix should actually work but it can make > sense to double check... > > Thanks, Sergey > > > Regards >> >> >> On 26 June 2014 13:50, Sergey Beryozkin <[email protected]> wrote: >> >> On 26/06/14 17:28, Sergey Beryozkin wrote: >>> >>> Hi >>>> On 26/06/14 13:11, [email protected] wrote: >>>> >>>> Hi Sergey, >>>>> >>>>> thanks for your prompt response. You are right, what I saw in the heap >>>>> dump >>>>> were links to the provider class, which prevented the classloader from >>>>> being garbage collected. >>>>> >>>>> The provider in question is registered via the standard JAX-RS means, >>>>> in >>>>> the getSingletons method of javax.ws.rs.core.Application. This is done >>>>> this >>>>> way because we need to configure the JacksonJaxbJsonProvider. >>>>> >>>>> >>>>> I've confirmed that the context info JAX-RS provider stored on the Bus >>>> contains the actual provider classes - this needs to be fixed. >>>> I'll look into it >>>> >>>> This is ok in itself but due to Tomee having a default bus shared >>> between >>> the endpoints it becomes a problem after redeployments. >>> >>> Hmm... I'll need to think how to overcome it... >>> >>> Cheers, Sergey >>> >>> >>> >>> >>> Thanks, Sergey >>>> >>>> I'll check with the Tomee team to see if endpoint specific buses are >>>> >>>>> possible. >>>>> >>>>> Thanks a lot. >>>>> >>>>> >>>>> On 26 June 2014 07:10, Sergey Beryozkin <[email protected]> wrote: >>>>> >>>>> Hi >>>>> >>>>>> >>>>>> On 26/06/14 04:32, [email protected] wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>>> >>>>>>> hope you are doing well. We've been using Tomee as our application >>>>>>> server >>>>>>> lately (we have some basic JAX-RS APIs), and after several >>>>>>> redeployments >>>>>>> we >>>>>>> get a PermGen space error. I've been digging into the heap dump, and >>>>>>> from >>>>>>> what I see our custom JAX-RS provider (JacksonJaxbJsonProvider) is >>>>>>> being >>>>>>> referenced inside ExtensionManagerBus's properties and never >>>>>>> unregistered. >>>>>>> >>>>>>> I'm pretty sure it's Tomee's fault, because it should be doing due >>>>>>> cleanup >>>>>>> on undeployment, but I was wondering whether the ExtensionManagerBus >>>>>>> has >>>>>>> any way of removing the registered providers. >>>>>>> >>>>>>> CXF JAX-RS checks provider context properties when it registers >>>>>>> >>>>>>> providers and stores reflection-specific information and proxies on >>>>>> the >>>>>> bus, it does not store the actual providers. >>>>>> >>>>>> Do you have some more info how Bus ends up linking to the provider ? >>>>>> We have a feature allowing providers registered directly on the bus >>>>>> via >>>>>> bus properties, is it what is being done in your case ? >>>>>> >>>>>> If not then I'm not sure. ProviderFactory holding providers is >>>>>> registered >>>>>> on the endpoint but I'm not seeing the code where the endpoint is >>>>>> registered on the bus. >>>>>> >>>>>> Either way, the problem appears to be originating from the fact that a >>>>>> single shared bus is used between multiple endpoints in Tomee. Is it >>>>>> possible in Tomee endpoint descriptors set up an endpoint specific >>>>>> bus ? >>>>>> For example, in Spring/Blueprint descriptors which can declare a new >>>>>> CXF >>>>>> Bus and have jaxrs/jaxws endpoints linking to it and this bus would be >>>>>> recycled on the redeployment. >>>>>> >>>>>> So, please let me know: >>>>>> - if you have more info about the link from Bus to providers >>>>>> - check if providers are registered directly on the bus (check its >>>>>> properties like "javax.ws.rs.ext.MessageBodyReader") >>>>>> - check if Tomee allows creating endpoint specific buses >>>>>> >>>>>> Lets us know please how it goes >>>>>> >>>>>> Thanks, Sergey >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Any help would be appreaciated >>>>>> >>>>>> Thanks in advance. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >> > > -- > Sergey Beryozkin > > Talend Community Coders > http://coders.talend.com/ > > Blog: http://sberyozkin.blogspot.com >
