DO NOT REPLY [Bug 38716] - Memory leaking on application undeployment, reload: solution to problem.

2006-02-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38716





--- Additional Comments From [EMAIL PROTECTED]  2006-02-21 13:24 ---
(In reply to comment #11)
> Re comment #8: Can you save me the absolutely assholish attitude, please?
> 
> Sorry for intruding in your totalitarian kingdom, Remy.. So very stupid of me.

I'm glad you appreciate it :)


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 38716] - Memory leaking on application undeployment, reload: solution to problem.

2006-02-21 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38716





--- Additional Comments From [EMAIL PROTECTED]  2006-02-21 12:29 ---
Re comment #8: Can you save me the absolutely assholish attitude, please?

Sorry for intruding in your totalitarian kingdom, Remy.. So very stupid of me.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 38716] - Memory leaking on application undeployment, reload: solution to problem.

2006-02-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38716





--- Additional Comments From [EMAIL PROTECTED]  2006-02-21 00:07 ---
(In reply to comment #9)
> Tomcat already shrinks and grows thread pools dynamically.

Tomcat hasn't been doing that for a long time. Shrinking thread pools may also
be a source of leaks, BTW.

> Not sure what is so bad about that idea?

It's a bit obvious: it is impractical. The only solution is to shut down the
whole thread pool, and start over. As a result, it's completely useless except
in very specific cases, and for these cases, specific solutions should be used
since they would perform much better (filters, listeners, fixes to the libs, 
etc).


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 38716] - Memory leaking on application undeployment, reload: solution to problem.

2006-02-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38716





--- Additional Comments From [EMAIL PROTECTED]  2006-02-20 21:40 ---
I would have to disagree with the abrasive answer. Tomcat already shrinks and
grows thread pools dynamically. When an app reload happens, it could mark
threads to expire after serving the next request or when the connection closes,
and serve new requests on new threads that will be fresh.

not sure what is so bad about that idea?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 38716] - Memory leaking on application undeployment, reload: solution to problem.

2006-02-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38716





--- Additional Comments From [EMAIL PROTECTED]  2006-02-20 17:39 ---
(In reply to comment #7)
> As I tried to point out in the inital description, the "resolution" to these
> problems might lay within libraries that are _not possible_ to reach for a
> webapp developer.
> 
> Your suggestion for resolution is then "don't use those libraries"?
> 
> I had hoped that Tomcat would be pragmatic in this regard, and actually try to
> supply a server that "works out of the box", given the problems that are 
> present
> in the environment, even if this is a problem with the core java classes as 
> such.
> 
> It seems like absolutely no-one that uses Tomcat can get reloading to work
> properly without getting memory-leaks. The reason for this is rather throughly
> explained in this enhancement request, and a solutions is proposed.
> 
> Why is it that you basically just "hate this to death" in such a way? What is
> generically wrong with being able to "cycle" the threadpools, e.g. by 
> requesting
> a particular link in the monitor?

Can you save us the whining, please ?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 38716] - Memory leaking on application undeployment, reload: solution to problem.

2006-02-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38716





--- Additional Comments From [EMAIL PROTECTED]  2006-02-20 17:23 ---
As I tried to point out in the inital description, the "resolution" to these
problems might lay within libraries that are _not possible_ to reach for a
webapp developer.

Your suggestion for resolution is then "don't use those libraries"?

I had hoped that Tomcat would be pragmatic in this regard, and actually try to
supply a server that "works out of the box", given the problems that are present
in the environment, even if this is a problem with the core java classes as 
such.

It seems like absolutely no-one that uses Tomcat can get reloading to work
properly without getting memory-leaks. The reason for this is rather throughly
explained in this enhancement request, and a solutions is proposed.

Why is it that you basically just "hate this to death" in such a way? What is
generically wrong with being able to "cycle" the threadpools, e.g. by requesting
a particular link in the monitor?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 38716] - Memory leaking on application undeployment, reload: solution to problem.

2006-02-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38716





--- Additional Comments From [EMAIL PROTECTED]  2006-02-20 15:56 ---
(In reply to comment #5)
> An alternative (which I don't seem to like) is to use time to live for 
> threads.
> Once a thread has lived for X amount of time or served Y requests - it will be
> "terminated". This could allow threadlocals go away, but an OOM could still
> occur if the required amount of time/requests is not reached. 
> 
> This approach mirrors the apache process model where you can request processes
> terminate after so many requests. (But comparing threads to processes is like
> not the greatest analogy)

I hate this approach too.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 38716] - Memory leaking on application undeployment, reload: solution to problem.

2006-02-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38716





--- Additional Comments From [EMAIL PROTECTED]  2006-02-20 15:47 ---
An alternative (which I don't seem to like) is to use time to live for threads.
Once a thread has lived for X amount of time or served Y requests - it will be
"terminated". This could allow threadlocals go away, but an OOM could still
occur if the required amount of time/requests is not reached. 

This approach mirrors the apache process model where you can request processes
terminate after so many requests. (But comparing threads to processes is like
not the greatest analogy)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 38716] - Memory leaking on application undeployment, reload: solution to problem.

2006-02-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38716





--- Additional Comments From [EMAIL PROTECTED]  2006-02-20 15:34 ---
(In reply to comment #2)
> Is this some special tomcat-friendly way of saying "feel free to come with a
> patch, and we'll include it", or is there some long history of reasons for why
> this suggestion is so utterly and totally lame that it don't even deserve a
> single line of explaination for why it is rejected?

You should use whatever custom solutions are needed for each webapp, and I don't
like the generic solution.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 38716] - Memory leaking on application undeployment, reload: solution to problem.

2006-02-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38716





--- Additional Comments From [EMAIL PROTECTED]  2006-02-20 15:09 ---
I agree with Endre. 
It can be a problem to use the ThreadLocal in thread pool environment, as
explained. IMHO, if tomcat have the proposed feature, it would be good to
improve the stability of the applications.
Can you explain a bit more why it won't be fixed?


 


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 38716] - Memory leaking on application undeployment, reload: solution to problem.

2006-02-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38716





--- Additional Comments From [EMAIL PROTECTED]  2006-02-20 14:41 ---
Why is this a blatant, non-explained WONTFIX?

Is this some special tomcat-friendly way of saying "feel free to come with a
patch, and we'll include it", or is there some long history of reasons for why
this suggestion is so utterly and totally lame that it don't even deserve a
single line of explaination for why it is rejected?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 38716] - Memory leaking on application undeployment, reload: solution to problem.

2006-02-20 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38716


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2006-02-20 13:56 ---
Feel free to use your own custom Tomcat version :)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]