I've committed the fix to 2.6.14-SNAPSHOT
Cheers, Sergey
On 26/06/14 22:25, Sergey Beryozkin wrote:
Hi,
On 26/06/14 22:23, [email protected] wrote:
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.
Sounds good, we have a couple of weeks or so before 2.6.x gets released
Thanks, Sergey
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
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
