public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
* kawa and apache tomcat
@ 2016-01-15 10:53 Damien MATTEI
  2016-01-15 18:10 ` Matthieu Vachon
  0 siblings, 1 reply; 4+ messages in thread
From: Damien MATTEI @ 2016-01-15 10:53 UTC (permalink / raw)
  To: kawa


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 code hosted on the apache tomcat web server,
all works fine but i noticed this when stopping the application (named Sidonie) 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.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Sidonie] created a ThreadLocal with key of type [gnu.mapping.Environment.InheritedLocal] (value [gnu.mapping.Environment$InheritedLocal@3dc806b8]) and a value of type [gnu.mapping.InheritingEnvironment] (value [#<environment http-nio-8080-exec-19>]) 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.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Sidonie] created a ThreadLocal with key of type [java.lang.InheritableThreadLocal] (value [java.lang.InheritableThreadLocal@7927031f]) and a value of type [kawa.standard.Scheme] (value [kawa.standard.Scheme@3070d094]) 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.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Sidonie] created a ThreadLocal with key of type [gnu.mapping.ThreadLocation.ThreadLocalWithDefault] (value [gnu.mapping.ThreadLocation$ThreadLocalWithDefault@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.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Sidonie] created a ThreadLocal with key of type [gnu.mapping.ThreadLocation.ThreadLocalWithDefault] (value [gnu.mapping.ThreadLocation$ThreadLocalWithDefault@6b51425b]) and a value of type [gnu.kawa.io.BinaryOutPort] (value [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 should free them by myself in  the code but scheme and java have their own garbage collector and normally deallocate ressource when no more in use, i use files 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: kawa and apache tomcat
  2016-01-15 10:53 kawa and apache tomcat Damien MATTEI
@ 2016-01-15 18:10 ` Matthieu Vachon
  2016-01-15 18:41   ` Per Bothner
  0 siblings, 1 reply; 4+ messages in thread
From: Matthieu Vachon @ 2016-01-15 18:10 UTC (permalink / raw)
  To: Damien MATTEI; +Cc: kawa

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/b7e574c4edeaedaf657960801791534f27e6216c/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 <Damien.Mattei@unice.fr> wrote:
>
> 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 code hosted on the apache tomcat web server,
> all works fine but i noticed this when stopping the application (named Sidonie) 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.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Sidonie] created a ThreadLocal with key of type [gnu.mapping.Environment.InheritedLocal] (value [gnu.mapping.Environment$InheritedLocal@3dc806b8]) and a value of type [gnu.mapping.InheritingEnvironment] (value [#<environment http-nio-8080-exec-19>]) 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.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Sidonie] created a ThreadLocal with key of type [java.lang.InheritableThreadLocal] (value [java.lang.InheritableThreadLocal@7927031f]) and a value of type [kawa.standard.Scheme] (value [kawa.standard.Scheme@3070d094]) 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.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Sidonie] created a ThreadLocal with key of type [gnu.mapping.ThreadLocation.ThreadLocalWithDefault] (value [gnu.mapping.ThreadLocation$ThreadLocalWithDefault@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.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Sidonie] created a ThreadLocal with key of type [gnu.mapping.ThreadLocation.ThreadLocalWithDefault] (value [gnu.mapping.ThreadLocation$ThreadLocalWithDefault@6b51425b]) and a value of type [gnu.kawa.io.BinaryOutPort] (value [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 should free them by myself in  the code but scheme and java have their own garbage collector and normally deallocate ressource when no more in use, i use files 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: kawa and apache tomcat
  2016-01-15 18:10 ` Matthieu Vachon
@ 2016-01-15 18:41   ` Per Bothner
  2016-01-19 14:07     ` Damien MATTEI
  0 siblings, 1 reply; 4+ messages in thread
From: Per Bothner @ 2016-01-15 18:41 UTC (permalink / raw)
  To: Matthieu Vachon, Damien MATTEI; +Cc: kawa

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]



On 01/15/2016 10:10 AM, Matthieu Vachon wrote:


> 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.

As I understand it, the problem is not normal usage, but when a servlet is re-loaded.
That creates a new ClassLoader, with a new set of Classes which causes
some complicated interaction with the GC (which I don't properly understand).

In normal usage,with no ClassLoader churn, there might be some temporary leak,
but the garbage should become collectible when a thread services a new request.

Could you try the attached patch?  I haven't actually tested it (except
to verify it compiles).  Let me know if it makes a difference.
It is possible it might *reduce* the number but not eliminate the
warnings.  If so, we would be on the right track, though with more to do.

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

[-- Attachment #2: servet.patch --]
[-- Type: text/x-patch, Size: 1849 bytes --]

Index: gnu/kawa/servlet/KawaServlet.java
===================================================================
--- gnu/kawa/servlet/KawaServlet.java	(revision 8666)
+++ gnu/kawa/servlet/KawaServlet.java	(working copy)
@@ -41,17 +41,9 @@
     throws ServletException, IOException
   {
     CallContext ctx = CallContext.getInstance();
-    HttpRequestContext hctx = HttpRequestContext.instance.get();
-    Context sctx;
-    if (hctx instanceof Context)
-      sctx = (Context) hctx;
-    else
-      {
-        sctx = new Context();
-        Context.setInstance(sctx);
-      }
-    sctx.init(this, request, response);
+    Context sctx = new Context(this, request, response);
     ctx.consumer = sctx.getConsumer();
+    Context.setInstance(sctx);
     // FIXME should path be relative to context?
     Path.setCurrentPath(Path.valueOf(request.getRequestURL().toString()));
     ctx.values = Values.noArgs;
@@ -100,6 +92,7 @@
       }
     finally
       {
+        Context.setInstance(null);
         sctx.servlet = null;
         sctx.request = null;
         sctx.response = null;
@@ -115,8 +108,8 @@
     ServletContext context;
     Map<String,Object> requestParameters;
 
-    public void init(HttpServlet servlet, HttpServletRequest request,
-                     HttpServletResponse response)
+    public Context(HttpServlet servlet, HttpServletRequest request,
+                   HttpServletResponse response)
     {
       if (response == null)
         throw new Error("init with null response");
@@ -317,7 +310,7 @@
     public List<String> getRequestHeaders (String name)
     {
       java.util.Enumeration<java.lang.String> e = request.getHeaders(name);
-      List<String> list = new ArrayList();
+      List<String> list = new ArrayList<String>();
       while (e.hasMoreElements())
         {
           list.add(e.nextElement());

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: kawa and apache tomcat
  2016-01-15 18:41   ` Per Bothner
@ 2016-01-19 14:07     ` Damien MATTEI
  0 siblings, 0 replies; 4+ messages in thread
From: Damien MATTEI @ 2016-01-19 14:07 UTC (permalink / raw)
  To: kawa

Hi Mathieu and Per,

sorry for my late answer but i was outside from office for few days,
thank you for your answers, i tried a patch on  the 2.A sources of kawa,  just have few problem to patch it ( i hadn't use patch command for more than a decade),hope it'es the good way:
 mattei@moita kawa-2.1]$ patch < servet.patch 
(Stripping trailing CRs from patch; use --binary to disable.)
can't find file to patch at input line 5
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Index: gnu/kawa/servlet/KawaServlet.java
|===================================================================
|--- gnu/kawa/servlet/KawaServlet.java  (revision 8666)
|+++ gnu/kawa/servlet/KawaServlet.java  (working copy)
--------------------------
File to patch: gnu/kawa/servlet/KawaServlet.java 
patching file gnu/kawa/servlet/KawaServlet.java

and run make to compile kawa-2.1. jar with sources patched and add it in the netbeans project the way i do it all the day to make a .war application ,deployed it on the apache tomacat8 server
but the warnings are still here in the logs when i stop the application in tomcat8:
19-Jan-2016 11:47:28.131 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Sidonie] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@1758bda9]) and a value of type [gnu.mapping.CallContext] (value [gnu.mapping.CallContext@7c41808c]) 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.
19-Jan-2016 11:47:28.131 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Sidonie] created a ThreadLocal with key of type [gnu.mapping.ThreadLocation.ThreadLocalWithDefault] (value [gnu.mapping.ThreadLocation$ThreadLocalWithDefault@4f731308]) and a value of type [gnu.kawa.io.BinaryOutPort] (value [gnu.kawa.io.BinaryOutPort@3dcceb4c]) 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.
19-Jan-2016 11:47:28.132 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Sidonie] created a ThreadLocal with key of type [gnu.mapping.Environment.InheritedLocal] (value [gnu.mapping.Environment$InheritedLocal@6f2bbca9]) and a value of type [gnu.mapping.InheritingEnvironment] (value [#<environment http-nio-8080-exec-19>]) 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.
19-Jan-2016 11:47:28.132 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Sidonie] created a ThreadLocal with key of type [gnu.kawa.io.Path$1] (value [gnu.kawa.io.Path$1@4822bf88]) and a value of type [gnu.kawa.io.FilePath] (value [/root]) 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.
19-Jan-2016 11:47:28.132 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Sidonie] created a ThreadLocal with key of type [java.lang.InheritableThreadLocal] (value [java.lang.InheritableThreadLocal@2012835b]) and a value of type [kawa.standard.Scheme] (value [kawa.standard.Scheme@4f423c7d]) 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.
19-Jan-2016 11:47:28.133 SEVERE [http-nio-8080-exec-11] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Sidonie] created a ThreadLocal with key of type [gnu.mapping.ThreadLocation.ThreadLocalWithDefault] (value [gnu.mapping.ThreadLocation$ThreadLocalWithDefault@12c104e2]) 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.

unless you have others ideas i will continue because i do not think it is critical for now, if under some server load it was a problem i will notice it , anyway i'm melting and compiling java pure source with scheme code in java byte-code in kawa but also in bigloo (another scheme for C and that ahave also a java front end) so if there would be a real problem
 i can easily migrate kawa scheme routines in bigloo scheme routines if it was necessary. 

Regards,
Damien

Le Friday 15 January 2016 19:41:00, vous avez écrit :
> 
> On 01/15/2016 10:10 AM, Matthieu Vachon wrote:
> 
> 
> > 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.
> 
> As I understand it, the problem is not normal usage, but when a servlet is re-loaded.
> That creates a new ClassLoader, with a new set of Classes which causes
> some complicated interaction with the GC (which I don't properly understand).
> 
> In normal usage,with no ClassLoader churn, there might be some temporary leak,
> but the garbage should become collectible when a thread services a new request.
> 
> Could you try the attached patch?  I haven't actually tested it (except
> to verify it compiles).  Let me know if it makes a difference.
> It is possible it might *reduce* the number but not eliminate the
> warnings.  If so, we would be on the right track, though with more to do.
> 



-- 
Damien.Mattei@unice.fr, Damien.Mattei@oca.eu, UNS / OCA / CNRS

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-01-19 14:07 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-15 10:53 kawa and apache tomcat Damien MATTEI
2016-01-15 18:10 ` Matthieu Vachon
2016-01-15 18:41   ` Per Bothner
2016-01-19 14:07     ` Damien MATTEI

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).