From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15041 invoked by alias); 15 Jan 2016 18:10:40 -0000 Mailing-List: contact kawa-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: kawa-owner@sourceware.org Received: (qmail 14985 invoked by uid 89); 15 Jan 2016 18:10:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.2 required=5.0 tests=AWL,BAYES_40,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=ressource, renewed, uns, damien X-HELO: mail-io0-f174.google.com Received: from mail-io0-f174.google.com (HELO mail-io0-f174.google.com) (209.85.223.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 15 Jan 2016 18:10:38 +0000 Received: by mail-io0-f174.google.com with SMTP id g73so300981897ioe.3 for ; Fri, 15 Jan 2016 10:10:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fHmK719q28v6AqwCMFHFnJi7RG8dg7C5YZbzQjpixFc=; b=jjNOLK3SU2Fr6bTeYrkeUtxhq27Pii3UZbz18kXxZh9UtF0aJ+cLeVm5fWJpDml5hZ z8nAmBlkb2kFyFP5Fil5aK8HfJQfoGQl0dkYUw9x8mZ3gHI9pNW2a6udi5aZLO5ItN9e 7DsuoPv7SfO8vHDYstVcyelUFq2AjAeNzCBKRiyz+P1YSCQbEZYNovWNWpTVvIVA0otU /KGa79NIJmJEJtNBIQezi+DiHeMdOb99zGmQpyoE4vp6y4Bk4y3NtSlirAEeVzXKhfSj /p04OGSNBQrmm8DQUstfI+cAgssd8prxwL9j+WFJMhzZKQmYsqWzKspx3D++iD2cpn/8 j5wg== X-Gm-Message-State: ALoCoQkvDGrZRIct9C9JNluR+QV3PxNmF/6bcKxmzyH0zwgilecmDXYo+vyvp962leMMSww/rjgNMMnS8jeZjVgidBkLWUKHxw== MIME-Version: 1.0 X-Received: by 10.107.158.3 with SMTP id h3mr10947751ioe.59.1452881436103; Fri, 15 Jan 2016 10:10:36 -0800 (PST) Received: by 10.79.104.4 with HTTP; Fri, 15 Jan 2016 10:10:36 -0800 (PST) In-Reply-To: <201601151145.23595.Damien.Mattei@unice.fr> References: <201601151145.23595.Damien.Mattei@unice.fr> Date: Fri, 15 Jan 2016 18:10:00 -0000 Message-ID: Subject: Re: kawa and apache tomcat From: Matthieu Vachon To: Damien MATTEI Cc: "kawa@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-q1/txt/msg00002.txt.bz2 Hi Damien, We've face a similar issue in the past and here a start of explanation, anyone can correct me if they see any mistake. You're running inside a servlet container which is responsible of executing request reaching it. To do so, the container held a thread pool so it can serve request. When a request reach the container, it picks a thread from the thread pool which is then used to execute the request. In this thread, at some point, you are reaching your Kawa code. The kawa code stores a few `ThreadLocal` variables which are saved in the thread given by the servlet container. However, Kawa does not release these thread locals when code exits his scope of action. The request completes and the container take back the thread given to you. I guess then that the container now sees that some thread local were added to thread without being discarded before reclaiming the thread and warn you about it. Depending on what is stored in the thread local storage and if the threads in the thread pool are renewed or not, memory leak can be occur because of this. For example, the `gnu.mapping.Environment` set some stuff but does not remove what it adds (as least I did not find the call). This is not a problem in a standard JVM application because once the application closes, nothing needs to be done. But in a container environment, that's another story since thread a kinda re-used over multiple requests. On high load, this can create huge memory leaks depending on the what is actually stored. In our case, we are in a rather old version of Kawa. We patched our version so that all thread locals are stored in a global structure. In a servlet context listener, we then call a clean up method just before finishing the request. We also add to work around a shutdown hook register which was causing some leaking problems in a servlet container application because it was registered but never removed (https://github.com/maoueh/kawa-fork/blob/b7e574c4edeaedaf657960801791534f2= 7e6216c/gnu/kawa/io/WriterManager.java#L86). Since you are on the latest version of Kawa, I guess fixing Kawa could be feasible. The inverse of register scheme environment should probably added so that it can be called once the actual request as been processed to clean up any resources still held by Kawa. Overall, maybe it there could be a single register scheme once the container is loaded and again a single unregister once the container is shutdown. I don't enough of the Kawa bootstrap process to known if this would be easy and even feasible. Hope this helped you a bit. Regards, Matt On Fri, Jan 15, 2016 at 5:45 AM, Damien MATTEI wro= te: > > hi, > > i 'm developping and testing a servlet application in tomcat 8 using some= kawa code byte-compiled for java, so there is pure java code and kawa cod= e hosted on the apache tomcat web server, > all works fine but i noticed this when stopping the application (named Si= donie) in tomcat manager, tomcat complains about this in the log files: > > 15-Jan-2016 11:08:49.115 SEVERE [http-nio-8080-exec-12] org.apache.catali= na.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web applica= tion [Sidonie] created a ThreadLocal with key of type [gnu.mapping.Environm= ent.InheritedLocal] (value [gnu.mapping.Environment$InheritedLocal@3dc806b8= ]) and a value of type [gnu.mapping.InheritingEnvironment] (value [#]) but failed to remove it when the web applica= tion was stopped. Threads are going to be renewed over time to try and avoi= d a probable memory leak. > 15-Jan-2016 11:08:49.116 SEVERE [http-nio-8080-exec-12] org.apache.catali= na.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web applica= tion [Sidonie] created a ThreadLocal with key of type [java.lang.Inheritabl= eThreadLocal] (value [java.lang.InheritableThreadLocal@7927031f]) and a val= ue of type [kawa.standard.Scheme] (value [kawa.standard.Scheme@3070d094]) b= ut failed to remove it when the web application was stopped. Threads are go= ing to be renewed over time to try and avoid a probable memory leak. > 15-Jan-2016 11:08:49.116 SEVERE [http-nio-8080-exec-12] org.apache.catali= na.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web applica= tion [Sidonie] created a ThreadLocal with key of type [gnu.mapping.ThreadLo= cation.ThreadLocalWithDefault] (value [gnu.mapping.ThreadLocation$ThreadLoc= alWithDefault@599f5a94]) and a value of type [gnu.math.IntNum] (value [10])= but failed to remove it when the web application was stopped. Threads are = going to be renewed over time to try and avoid a probable memory leak. > 15-Jan-2016 11:08:49.116 SEVERE [http-nio-8080-exec-12] org.apache.catali= na.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web applica= tion [Sidonie] created a ThreadLocal with key of type [gnu.mapping.ThreadLo= cation.ThreadLocalWithDefault] (value [gnu.mapping.ThreadLocation$ThreadLoc= alWithDefault@6b51425b]) and a value of type [gnu.kawa.io.BinaryOutPort] (v= alue [gnu.kawa.io.BinaryOutPort@4cf02060]) but failed to remove it when the= web application was stopped. Threads are going to be renewed over time to = try and avoid a probable memory leak. > > this message appear the same number of times as the kawa code is called ,= for example if i reload the web page which call again the kawa code i will = have two instance of this message in log ... > > for info my kawa code are called after a Scheme.registerEnvironment(); > > tomcat seems cannot be able to free some kawa ressource, perheaps i shoul= d free them by myself in the code but scheme and java have their own garba= ge collector and normally deallocate ressource when no more in use, i use f= iles with diffrent method too, when i do an > open ,i close the file at end but not always when using some method such = as gnu.list.blob... > > any ideas? > > regards, > damien > -- > Damien.Mattei@unice.fr, Damien.Mattei@oca.eu, UNS / OCA / CNRS