34 messages in org.codehaus.groovy.devRe: [groovy-dev] Re: [groovy-user] Me...
FromSent OnAttachments
Alex TkachmanOct 16, 2008 2:30 pm 
Alex TkachmanOct 16, 2008 3:17 pm 
Jochen TheodorouOct 16, 2008 3:49 pm 
Tim QuinnOct 16, 2008 4:15 pm 
Alexander VeitOct 16, 2008 4:34 pm 
Jochen TheodorouOct 16, 2008 4:43 pm 
Tim QuinnOct 16, 2008 5:28 pm 
Jochen TheodorouOct 17, 2008 6:35 am 
Alex TkachmanOct 17, 2008 6:44 am 
Graeme RocherOct 17, 2008 6:54 am 
Jochen TheodorouOct 17, 2008 7:05 am 
Graeme RocherOct 17, 2008 7:14 am 
alex...@gmail.comOct 17, 2008 7:30 am 
Jochen TheodorouOct 17, 2008 7:36 am 
Alex TkachmanOct 17, 2008 9:51 am 
Jochen TheodorouOct 22, 2008 5:27 am 
Alex TkachmanOct 22, 2008 5:37 am 
Jochen TheodorouOct 22, 2008 6:05 am 
Alex TkachmanOct 22, 2008 6:08 am 
Jochen TheodorouOct 22, 2008 6:18 am.zip
Alex TkachmanOct 22, 2008 6:32 am 
Jochen TheodorouOct 22, 2008 7:06 am 
Guillaume LaforgeOct 22, 2008 7:08 am 
Alex TkachmanOct 22, 2008 7:11 am 
Guillaume LaforgeOct 22, 2008 7:21 am 
Jochen TheodorouOct 22, 2008 7:22 am 
Jochen TheodorouOct 22, 2008 7:39 am 
Jochen TheodorouOct 22, 2008 7:41 am 
Alex TkachmanOct 22, 2008 9:16 am 
Jochen TheodorouOct 22, 2008 10:11 am 
Jochen TheodorouOct 22, 2008 11:24 am 
Alex TkachmanOct 22, 2008 11:48 am 
Jochen TheodorouOct 22, 2008 2:07 pm 
Jochen TheodorouDec 22, 2008 12:52 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [groovy-dev] Re: [groovy-user] Memory leaks in GroovyActions...
From:Tim Quinn (Timo@Sun.COM)
Date:Oct 16, 2008 5:28:51 pm
List:org.codehaus.groovy.dev

Jochen Theodorou wrote:;

is not Thread, it is a annonymous inner class Ah, yes, that's true.

What I saw as I did the memory analysis on this is that the thread's contextClassLoader is the WebappClassLoader, and that is because the thread which creates this one has the WebappClassLoader for its contextClassLoader and the new thread takes its creator's ccl.

yes, that we need to change too... in fact that is a very fast change, as any we can simply set the bootloader as context loader for this thread.. but can the class be collected if there is a deamon still running with a class that is loaded by that thread?

No, I believe you are right about that. It would be better for any number of reasons for the thread to stop when its usefulness is past.

Perhaps the logic you described would work for discriminating among the various profiles; I'm nowhere near familiar enough with Groovy to have an opinion about that. But is it reasonable to provide a public API which an application or a container could invoke to close down Groovy in an orderly manner which would include running down this thread?

Well, was never needed before... so there is not yet such an API... also it should be possible to use Groovy as library and normally you don't clean up behind a library. So at last there should be something that solves the problem automatically.

Something automatic would indeed be best, if possible and reliable.

It's great to see the quick and thoughtful responses to these questions.

- Tim