Return-Path: 
 <users-return-45015-apmail-cxf-users-archive=cxf.apache.org@cxf.apache.org>
X-Original-To: apmail-cxf-users-archive@www.apache.org
Delivered-To: apmail-cxf-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id C916F11D68
	for <apmail-cxf-users-archive@www.apache.org>;
 Thu, 26 Jun 2014 18:12:39 +0000 (UTC)
Received: (qmail 65381 invoked by uid 500); 26 Jun 2014 18:12:39 -0000
Delivered-To: apmail-cxf-users-archive@cxf.apache.org
Received: (qmail 65311 invoked by uid 500); 26 Jun 2014 18:12:39 -0000
Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@cxf.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@cxf.apache.org>
List-Post: <mailto:users@cxf.apache.org>
List-Id: <users.cxf.apache.org>
Reply-To: users@cxf.apache.org
Delivered-To: mailing list users@cxf.apache.org
Received: (qmail 65299 invoked by uid 99); 26 Jun 2014 18:12:38 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Jun 2014 18:12:38 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of pablo.a.saavedra@gmail.com
 designates 209.85.219.51 as permitted sender)
Received: from [209.85.219.51] (HELO mail-oa0-f51.google.com) (209.85.219.51)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Jun 2014 18:12:34 +0000
Received: by mail-oa0-f51.google.com with SMTP id j17so4341449oag.38
        for <users@cxf.apache.org>; Thu, 26 Jun 2014 11:12:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=CLQ19K16GOgxZV5G2meqb71VPGpz2GnlOdvfco1evVQ=;
        b=SQ/6bKQWkpTBM1z+dv+bGZxVYc3d+Xkr4p8DG+B+LzZoIfiwlXWTc03e9b2Q0ynkyg
         8Su01h4UnYaMPeu3bTkm0M0EduRr74+tR7R2gsWa4UyauWfTuUx8qB4fpBXoStyLId7Q
         SDve+aUEy/XQ0TxBRkySg3UZogwTHhIWrGAsYrHDw4y27Ruj9WVp2KkigtRa0Z3vz95+
         yhWV4vW6YgWFHhEdoy56kNnDMwoqm+qTBVP0VLw4Z8aTrrt1tKXa3yDJAEqzMwKfgces
         ShV+J+th8GLcnl3fTKKg8aAVL1ggHNDAcCGE67EwDm7KGBXnlC3OrgkAOgmZKmSCn55e
         yk4Q==
MIME-Version: 1.0
X-Received: by 10.60.124.108 with SMTP id mh12mr17831365oeb.35.1403806329862;
 Thu, 26 Jun 2014 11:12:09 -0700 (PDT)
Received: by 10.182.161.42 with HTTP; Thu, 26 Jun 2014 11:12:09 -0700 (PDT)
In-Reply-To: <53AC4F6F.2040403@gmail.com>
References: 
 <CALtVYt8mcJx=fwXBuVwHPwWO92QJr98tLyc-YsntfkOQQSNVgg@mail.gmail.com>
	<53ABF188.7030205@gmail.com>
	<CALtVYt_oV3p7n_7gV12QqBbeTyEJ5cm72OsrYpjSkBao0_uh1A@mail.gmail.com>
	<53AC4A1C.1090603@gmail.com>
	<53AC4F6F.2040403@gmail.com>
Date: Thu, 26 Jun 2014 15:12:09 -0300
Message-ID: 
 <CALtVYt_MDvjiWu=W-x7uHvsn5XsZBn3MovvWdTa0gyLjGOoiPg@mail.gmail.com>
Subject: Re: Classloader leak in ExtensionManagerBus (on tomee)
From: "pablo.a.saavedra@gmail.com" <pablo.a.saavedra@gmail.com>
To: users@cxf.apache.org
Content-Type: multipart/alternative; boundary=047d7b5d30a4a0018104fcc12107
X-Virus-Checked: Checked by ClamAV on apache.org

--047d7b5d30a4a0018104fcc12107
Content-Type: text/plain; charset=UTF-8

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.

Let me know if I can be of any help.
Regards


On 26 June 2014 13:50, Sergey Beryozkin <sberyozkin@gmail.com> wrote:

> On 26/06/14 17:28, Sergey Beryozkin wrote:
>
>> Hi
>> On 26/06/14 13:11, pablo.a.saavedra@gmail.com 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 <sberyozkin@gmail.com> wrote:
>>>
>>>  Hi
>>>>
>>>> On 26/06/14 04:32, pablo.a.saavedra@gmail.com 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.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>

--047d7b5d30a4a0018104fcc12107--