RE: Memory leaks?
Try passing the jvm the -server option -Original Message- From: Jim Lynch [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 9:57 AM To: tomcat Subject: Memory leaks? I seemed to have read that java/tomcat isn't supposed to have memory leaks, but something seems to be running me out of memory and I don't know what. After a number of edit/undeploy/compile/deploy iterations I get the following: javax.servlet.ServletException: Servlet execution threw an exception at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:193) (Big snip) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne ction(Http11Protocol.java:392) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:619) at java.lang.Thread.run(Thread.java:536) root cause java.lang.OutOfMemoryError I'm running tomcat 4.1.24 on Linux with Apache 1.something. Java 1.4.1_02. So where do I start looking for the problem? If I forget to close Statements would that cause the problem? Thanks, Jim. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
Docs indicate that leaving a stmt or rs object open can cause memory leaks.
Found the following in the tomcat docs somewhere, i think:
Here is an example of properly written code to use a db connection obtained
from a connection pool:
Connection conn = null;
Statement stmt = null; // Or PreparedStatement if needed
ResultSet rs = null;
try {
conn = ... get connection from connection pool ...
stmt = conn.createStatement("select ...");
rs = stmt.executeQuery();
... iterate through the result set ...
rs.close();
rs = null;
stmt.close();
stmt = null;
conn.close(); // Return to connection pool
conn = null; // Make sure we don't close it twice
} catch (SQLException e) {
... deal with errors ...
} finally {
// Always make sure result sets and statements are closed,
// and the connection is returned to the pool
if (rs != null) {
try { rs.close(); } catch (SQLException e) { ; }
rs = null;
}
if (stmt != null) {
try { stmt.close(); } catch (SQLException e) { ; }
stmt = null;
}
if (conn != null) {
try { conn.close(); } catch (SQLException e) { ; }
conn = null;
}
}
- Original Message -
From: "Jim Lynch" <[EMAIL PROTECTED]>
To: "tomcat" <[EMAIL PROTECTED]>
Sent: Wednesday, September 03, 2003 12:56 PM
Subject: Memory leaks?
> I seemed to have read that java/tomcat isn't supposed to have memory
> leaks, but something seems to be running me out of memory and I don't
> know what.
>
> After a number of edit/undeploy/compile/deploy iterations I get the
> following:
>
> javax.servlet.ServletException: Servlet execution threw an exception
> at
>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:269)
> at
>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
>
> (Big snip)
>
>
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:392)
> at
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
> at
>
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:619)
> at java.lang.Thread.run(Thread.java:536)
>
> root cause
>
> java.lang.OutOfMemoryError
>
> I'm running tomcat 4.1.24 on Linux with Apache 1.something. Java
> 1.4.1_02.
>
> So where do I start looking for the problem? If I forget to close
> Statements would that cause the problem?
>
> Thanks,
> Jim.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
OK, that's probably what's going on. I know I should close Statements
and Connections and do normally but I'm fairly certain I've some out
there dangling. I didn't know you had to close ResultSets, however.
Glad to know that.
Thanks,
Jim.
Paul wrote:
>
> Docs indicate that leaving a stmt or rs object open can cause memory leaks.
> Found the following in the tomcat docs somewhere, i think:
>
> Here is an example of properly written code to use a db connection obtained
> from a connection pool:
>
> Connection conn = null;
> Statement stmt = null; // Or PreparedStatement if needed
> ResultSet rs = null;
> try {
> conn = ... get connection from connection pool ...
> stmt = conn.createStatement("select ...");
> rs = stmt.executeQuery();
> ... iterate through the result set ...
> rs.close();
> rs = null;
> stmt.close();
> stmt = null;
> conn.close(); // Return to connection pool
> conn = null; // Make sure we don't close it twice
> } catch (SQLException e) {
> ... deal with errors ...
> } finally {
> // Always make sure result sets and statements are closed,
> // and the connection is returned to the pool
> if (rs != null) {
> try { rs.close(); } catch (SQLException e) { ; }
> rs = null;
> }
> if (stmt != null) {
> try { stmt.close(); } catch (SQLException e) { ; }
> stmt = null;
> }
> if (conn != null) {
> try { conn.close(); } catch (SQLException e) { ; }
> conn = null;
> }
> }
>
> - Original Message -
> From: "Jim Lynch" <[EMAIL PROTECTED]>
> To: "tomcat" <[EMAIL PROTECTED]>
> Sent: Wednesday, September 03, 2003 12:56 PM
> Subject: Memory leaks?
>
> > I seemed to have read that java/tomcat isn't supposed to have memory
> > leaks, but something seems to be running me out of memory and I don't
> > know what.
> >
> > After a number of edit/undeploy/compile/deploy iterations I get the
> > following:
> >
> > javax.servlet.ServletException: Servlet execution threw an exception
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
> FilterChain.java:269)
> > at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
> ain.java:193)
> >
> > (Big snip)
> >
> >
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
> ction(Http11Protocol.java:392)
> > at
> > org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
> > at
> >
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
> a:619)
> > at java.lang.Thread.run(Thread.java:536)
> >
> > root cause
> >
> > java.lang.OutOfMemoryError
> >
> > I'm running tomcat 4.1.24 on Linux with Apache 1.something. Java
> > 1.4.1_02.
> >
> > So where do I start looking for the problem? If I forget to close
> > Statements would that cause the problem?
> >
> > Thanks,
> > Jim.
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks?
In my experience this is not a good recommendation: - -server is less stable than -client in all JDK's that I tried, and this has been confirmed by several list members. - -server won't help much on out of memory errors. The gc is behaving differently, but it can't free more objects, they are just freed at different times. If you get a out of memory error, there rn't any object that can be freed. > -Original Message- > From: Richard Hill [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 03, 2003 7:40 PM > To: 'Tomcat Users List' > Subject: RE: Memory leaks? > > > Try passing the jvm the -server option > > -Original Message- > From: Jim Lynch [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 03, 2003 9:57 AM > To: tomcat > Subject: Memory leaks? > > I seemed to have read that java/tomcat isn't supposed to have memory > leaks, but something seems to be running me out of memory and I don't > know what. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : Memory leaks?
A question here : why do you put "rs.close(), rs = null, stmt.close(), stmt
= null etc" twice, in both "try" and "finally" statements ?
Since the "finally" statement is called whenever an exception is thrown or
not, you don't need to close rs, stmt and conn in the "try" statement
first...
Am I wrong here ?
Thanks
Alain
-Message d'origine-
De : Paul [mailto:[EMAIL PROTECTED]
Envoyé : mercredi, 3. septembre 2003 21:28
À : Tomcat Users List
Objet : Re: Memory leaks?
Docs indicate that leaving a stmt or rs object open can cause memory leaks.
Found the following in the tomcat docs somewhere, i think:
Here is an example of properly written code to use a db connection obtained
from a connection pool:
Connection conn = null;
Statement stmt = null; // Or PreparedStatement if needed
ResultSet rs = null;
try {
conn = ... get connection from connection pool ...
stmt = conn.createStatement("select ...");
rs = stmt.executeQuery();
... iterate through the result set ...
rs.close();
rs = null;
stmt.close();
stmt = null;
conn.close(); // Return to connection pool
conn = null; // Make sure we don't close it twice
} catch (SQLException e) {
... deal with errors ...
} finally {
// Always make sure result sets and statements are closed,
// and the connection is returned to the pool
if (rs != null) {
try { rs.close(); } catch (SQLException e) { ; }
rs = null;
}
if (stmt != null) {
try { stmt.close(); } catch (SQLException e) { ; }
stmt = null;
}
if (conn != null) {
try { conn.close(); } catch (SQLException e) { ; }
conn = null;
}
}
- Original Message -
From: "Jim Lynch" <[EMAIL PROTECTED]>
To: "tomcat" <[EMAIL PROTECTED]>
Sent: Wednesday, September 03, 2003 12:56 PM
Subject: Memory leaks?
> I seemed to have read that java/tomcat isn't supposed to have memory
> leaks, but something seems to be running me out of memory and I don't
> know what.
>
> After a number of edit/undeploy/compile/deploy iterations I get the
> following:
>
> javax.servlet.ServletException: Servlet execution threw an exception
> at
>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:269)
> at
>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
>
> (Big snip)
>
>
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:392)
> at
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:
> 565)
> at
>
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:619)
> at java.lang.Thread.run(Thread.java:536)
>
> root cause
>
> java.lang.OutOfMemoryError
>
> I'm running tomcat 4.1.24 on Linux with Apache 1.something. Java
> 1.4.1_02.
>
> So where do I start looking for the problem? If I forget to close
> Statements would that cause the problem?
>
> Thanks,
> Jim.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks?
Howdy, I completely agree with Senor Einfeldt's comments, having found exactly the same results in my experience with -server. Waiting for Tiger's -server fixes. To the original poster: any objects with dangling references may not be recycled when your app is restarted. These can have bad consequences, such as excessive memory use or stale data, or even tomcat-killing errors such as the dreaded CL: Lifecycle Stopped one ;) You should very carefully inspect your app to close all resources that you can: basically, if it has a public close()/shutdown()/terminate()/whatever function, use it ;) This applies to DB objects, such as the connection/statement/result set/connection pool, but also to others like JMS connections/sessions, mail sessions, transactions, etc. Yoav Shapira Millennium ChemInformatics >-Original Message- >From: Ralph Einfeldt [mailto:[EMAIL PROTECTED] >Sent: Thursday, September 04, 2003 2:00 AM >To: Tomcat Users List >Subject: RE: Memory leaks? > >In my experience this is not a good recommendation: > >- -server is less stable than -client in all JDK's that I tried, > and this has been confirmed by several list members. > >- -server won't help much on out of memory errors. The gc is > behaving differently, but it can't free more objects, they > are just freed at different times. If you get a out of memory > error, there rn't any object that can be freed. > >> -Original Message- >> From: Richard Hill [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, September 03, 2003 7:40 PM >> To: 'Tomcat Users List' >> Subject: RE: Memory leaks? >> >> >> Try passing the jvm the -server option >> >> -Original Message- >> From: Jim Lynch [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, September 03, 2003 9:57 AM >> To: tomcat >> Subject: Memory leaks? >> >> I seemed to have read that java/tomcat isn't supposed to have memory >> leaks, but something seems to be running me out of memory and I don't >> know what. >> > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
On 03 September 2003, Jim Lynch said: > OK, that's probably what's going on. I know I should close Statements > and Connections and do normally but I'm fairly certain I've some out > there dangling. I didn't know you had to close ResultSets, however. > Glad to know that. You don't have to close ResultSets -- check the JDBC docs: http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#close() (Closing a Statement also closes any open ResultSets associated with that Statement.) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks?
Howdy, You don't have to close a result set if you're closing the statement right away and the result set is the only one associated with the statement... And in no case can closing the result set explicitly hurt performance. Yoav Shapira Millennium ChemInformatics >-Original Message- >From: Greg Ward [mailto:[EMAIL PROTECTED] >Sent: Thursday, September 04, 2003 10:05 AM >To: Tomcat Users List; [EMAIL PROTECTED] >Subject: Re: Memory leaks? > >On 03 September 2003, Jim Lynch said: >> OK, that's probably what's going on. I know I should close Statements >> and Connections and do normally but I'm fairly certain I've some out >> there dangling. I didn't know you had to close ResultSets, however. >> Glad to know that. > >You don't have to close ResultSets -- check the JDBC docs: > > http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#close() > >(Closing a Statement also closes any open ResultSets associated with >that Statement.) > >Greg > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks?
But depending on the DB, it can cause problems from the DB with too many open ResultSets... I had an issue with performance testing where everything but ResultSets were being closed and the Oracle DB started throwing errors after about 500 queries. Better safe than sorry. -Original Message- From: Greg Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 9:05 AM To: Tomcat Users List; [EMAIL PROTECTED] Subject: Re: Memory leaks? On 03 September 2003, Jim Lynch said: > OK, that's probably what's going on. I know I should close Statements > and Connections and do normally but I'm fairly certain I've some out > there dangling. I didn't know you had to close ResultSets, however. > Glad to know that. You don't have to close ResultSets -- check the JDBC docs: http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#close() (Closing a Statement also closes any open ResultSets associated with that Statement.) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
> But depending on the DB, it can cause problems from the DB with too many > open ResultSets... I had an issue with performance testing where everything > but ResultSets were being closed and the Oracle DB started throwing errors > after about 500 queries. Better safe than sorry. Well, from what I know, in general (not Oracle specific). If you open a connection within some scope (Servlet, JSP, any other class), then create a statement and finally a result set, shouldn't deleting the most upper scope cause all these "lower levels" be closed and garbage collected? With Servlets and JSP, of course, you have no control whatsoever as to when they will be put out of service. But suppose you are tidy and do a close on the connection - shouldn't that clean-up the underlying Statement(s) and ResultSet(s)? Even with connection pooling, this should work. Nix.
Re: Memory leaks?
The JDBC spec states that when a connection is closed, all dependent assets should also be closed. So if you are using a pool, make sure your pool is compliant since the connection is never closed until the pool closes it. When garbage collection runs is a whole different story. But its just good coding to close your ResultSet, Statements as soon as your done with them. -Tim Nikola Milutinovic wrote: But depending on the DB, it can cause problems from the DB with too many open ResultSets... I had an issue with performance testing where everything but ResultSets were being closed and the Oracle DB started throwing errors after about 500 queries. Better safe than sorry. Well, from what I know, in general (not Oracle specific). If you open a connection within some scope (Servlet, JSP, any other class), then create a statement and finally a result set, shouldn't deleting the most upper scope cause all these "lower levels" be closed and garbage collected? With Servlets and JSP, of course, you have no control whatsoever as to when they will be put out of service. But suppose you are tidy and do a close on the connection - shouldn't that clean-up the underlying Statement(s) and ResultSet(s)? Even with connection pooling, this should work. Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
Tim Funk wrote: The JDBC spec states that when a connection is closed, all dependent assets should also be closed. So if you are using a pool, make sure your pool is compliant since the connection is never closed until the pool closes it. So, that means that if you have a pool of ten connections, and you use each of those ten connections ten times with 2 ResultSets, you have 200 ResultSets sitting in memory, assuming you don't close them yourself? John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
It depends. If your webapp calls connection.close(), then the result sets *should* be closed. But that is based one of the following assumptions: - Your connection is the actual db connection and the driver is JDBC compliant - The connection is a facade to the actual connection for the sake of using a database connection pool. And the facade is smart enough to close all dependent assets on that connection for you. I *try* to make my programmers only have one statement and result set open at a time per connection. If a second statement or result set needs opened, they should either close the existing resources or open another connection. They must always close ANYTHING they open. -Tim John Turner wrote: Tim Funk wrote: The JDBC spec states that when a connection is closed, all dependent assets should also be closed. So if you are using a pool, make sure your pool is compliant since the connection is never closed until the pool closes it. So, that means that if you have a pool of ten connections, and you use each of those ten connections ten times with 2 ResultSets, you have 200 ResultSets sitting in memory, assuming you don't close them yourself? John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
It's simple good practice to close objects that have close methods when you
no longer need them (as you do with stream objects, for example).
The spec says that ResultSet objects are closed when their Statement objects
are closed and that Statement objects are closed when their Connection
objects are closed. I personally like to keep hold of a Connection object
for the lifetime of my application (or until it fails), because connecting
to a database is an expensive operation. Also, if you use Connection
pooling, Connection objects can be kept open for as long as your application
server or whatever is running, so that unclosed Statements with their open
ResultSets simply sit around hogging resources (and some of the resources
that they hog, such as database cursors, are not lightweight).
This is what I do for JDBC calls:
// Assume a connection has been made
Connection conn...;
PreparedStatement ps = null;
ResultSet rs = null;
try {
// Create a PreparedStatement and use it to open a ResultSet
...
// Clean up
rs.close();
} catch (SQLException e) {
// Do something with the error
} finally {
try {
if (null != ps) {
ps.close();
} catch (SQLException e) {}
}
This guarantees that the objects are always closed (assuming, of course,
that the close() operations succeed). The rs.close() is, in theory,
unnecessary as the ps.close() call is supposed to close it implicitly, but
my background is in C and I always tried to free anything that I'd malloced.
It's a habit that's stuck.
In short, ALWAYS CLOSE YOUR STATEMENT OBJECTS.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
I'm most certain the connections are closed but there may be a few dangling statements. I'm using mysql jdbc. Not using pools since I never could get it working. Making direct requests. Still getting a out of memory hit every couple of days so I have to shutdown the server and start it up again. THnak,s Jim. "Shapira, Yoav" wrote: > > Howdy, > You don't have to close a result set if you're closing the statement > right away and the result set is the only one associated with the > statement... And in no case can closing the result set explicitly hurt > performance. > > Yoav Shapira > Millennium ChemInformatics > > >-Original Message- > >From: Greg Ward [mailto:[EMAIL PROTECTED] > >Sent: Thursday, September 04, 2003 10:05 AM > >To: Tomcat Users List; [EMAIL PROTECTED] > >Subject: Re: Memory leaks? > > > >On 03 September 2003, Jim Lynch said: > >> OK, that's probably what's going on. I know I should close > Statements > >> and Connections and do normally but I'm fairly certain I've some out > >> there dangling. I didn't know you had to close ResultSets, however. > >> Glad to know that. > > > >You don't have to close ResultSets -- check the JDBC docs: > > > > > http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#close() > > > >(Closing a Statement also closes any open ResultSets associated with > >that Statement.) > > > >Greg > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > This e-mail, including any attachments, is a confidential business communication, > and may contain information that is confidential, proprietary and/or privileged. > This e-mail is intended only for the individual(s) to whom it is addressed, and may > not be saved, copied, printed, disclosed or used by anyone else. If you are not > the(an) intended recipient, please immediately delete this e-mail from your computer > system and notify the sender. Thank you. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks?
After about 15 emails, I'm gonna go back to the first: > I seemed to have read that java/tomcat isn't > supposed to have memory leaks, AND > So where do I start looking for the problem? > If I forget to close Statements would that cause the > problem? So first of all, Java has built-in memory management and garbage collection, so comparing against a language like C++, it's MUCH harder to cause a memory leak in a Java program, *but not impossible*. And up to now we're focusing on JDBC. Connection pools and whether or not your driver strictly adheres to the JDBC standard are certainly one source of memory leaks. But they're not the only ones possible. What sorts of other activities are going on in your application? Do you have other 3rd party libraries? Libraries you've written yourself? Have these been profiled and exercised to ensure they are not the ones leaking? > -Original Message- > From: Jim Lynch [mailto:[EMAIL PROTECTED] > Sent: Friday, September 05, 2003 9:37 AM > To: Tomcat Users List > Subject: Re: Memory leaks? > > > I'm most certain the connections are closed but there may be > a few dangling statements. I'm using mysql jdbc. Not using > pools since I never could get it working. Making direct requests. > > Still getting a out of memory hit every couple of days so I > have to shutdown the server and start it up again. > > THnak,s > Jim. > > "Shapira, Yoav" wrote: > > > > Howdy, > > You don't have to close a result set if you're closing the > statement > > right away and the result set is the only one associated with the > > statement... And in no case can closing the result set > explicitly hurt > > performance. > > > > Yoav Shapira > > Millennium ChemInformatics > > > > >-Original Message- > > >From: Greg Ward [mailto:[EMAIL PROTECTED] > > >Sent: Thursday, September 04, 2003 10:05 AM > > >To: Tomcat Users List; [EMAIL PROTECTED] > > >Subject: Re: Memory leaks? > > > > > >On 03 September 2003, Jim Lynch said: > > >> OK, that's probably what's going on. I know I should close > > Statements > > >> and Connections and do normally but I'm fairly certain I've some > > >> out there dangling. I didn't know you had to close ResultSets, > > >> however. Glad to know that. > > > > > >You don't have to close ResultSets -- check the JDBC docs: > > > > > > > > > http://java.sun.com/j2se/1.4.2/docs/api/java/s> ql/Statement.html#close( > > ) > > > > > >(Closing a Statement also closes any open ResultSets > associated with > > >that Statement.) > > > > > >Greg > > > > > > >- > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > >For additional commands, e-mail: > [EMAIL PROTECTED] > > > > This e-mail, including any attachments, is a confidential business > > communication, and may contain information that is confidential, > > proprietary and/or privileged. This e-mail is intended > only for the > > individual(s) to whom it is addressed, and may not be > saved, copied, > > printed, disclosed or used by anyone else. If you are not the(an) > > intended recipient, please immediately delete this e-mail from your > > computer system and notify the sender. Thank you. > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaks?
I have no home grown libs, but I do have a lib for the "Split" function and the gnu-regex lib. Now that split is available in 1.4 I could convert to it and see if that helps. I have no idea how to profile and exercise a library, so I'd have to answer "no". Thanks, Jim. Mike Curwen wrote: > > After about 15 emails, I'm gonna go back to the first: > > > I seemed to have read that java/tomcat isn't > > supposed to have memory leaks, > > AND > > > So where do I start looking for the problem? > > If I forget to close Statements would that cause the > > problem? > > So first of all, Java has built-in memory management and garbage > collection, so comparing against a language like C++, it's MUCH harder > to cause a memory leak in a Java program, *but not impossible*. And up > to now we're focusing on JDBC. Connection pools and whether or not your > driver strictly adheres to the JDBC standard are certainly one source of > memory leaks. But they're not the only ones possible. What sorts of > other activities are going on in your application? Do you have other > 3rd party libraries? Libraries you've written yourself? Have these been > profiled and exercised to ensure they are not the ones leaking? > > > > -Original Message----- > > From: Jim Lynch [mailto:[EMAIL PROTECTED] > > Sent: Friday, September 05, 2003 9:37 AM > > To: Tomcat Users List > > Subject: Re: Memory leaks? > > > > > > I'm most certain the connections are closed but there may be > > a few dangling statements. I'm using mysql jdbc. Not using > > pools since I never could get it working. Making direct requests. > > > > Still getting a out of memory hit every couple of days so I > > have to shutdown the server and start it up again. > > > > THnak,s > > Jim. > > > > "Shapira, Yoav" wrote: > > > > > > Howdy, > > > You don't have to close a result set if you're closing the > > statement > > > right away and the result set is the only one associated with the > > > statement... And in no case can closing the result set > > explicitly hurt > > > performance. > > > > > > Yoav Shapira > > > Millennium ChemInformatics > > > > > > >-Original Message- > > > >From: Greg Ward [mailto:[EMAIL PROTECTED] > > > >Sent: Thursday, September 04, 2003 10:05 AM > > > >To: Tomcat Users List; [EMAIL PROTECTED] > > > >Subject: Re: Memory leaks? > > > > > > > >On 03 September 2003, Jim Lynch said: > > > >> OK, that's probably what's going on. I know I should close > > > Statements > > > >> and Connections and do normally but I'm fairly certain I've some > > > >> out there dangling. I didn't know you had to close ResultSets, > > > >> however. Glad to know that. > > > > > > > >You don't have to close ResultSets -- check the JDBC docs: > > > > > > > > > > > > > http://java.sun.com/j2se/1.4.2/docs/api/java/s> > ql/Statement.html#close( > > > ) > > > > > > > >(Closing a Statement also closes any open ResultSets > > associated with > > > >that Statement.) > > > > > > > >Greg > > > > > > > > > >- > > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > This e-mail, including any attachments, is a confidential business > > > communication, and may contain information that is confidential, > > > proprietary and/or privileged. This e-mail is intended > > only for the > > > individual(s) to whom it is addressed, and may not be > > saved, copied, > > > printed, disclosed or used by anyone else. If you are not the(an) > > > intended recipient, please immediately delete this e-mail from your > > > computer system and notify the sender. Thank you. > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory leaks?
may be a little off topic, but - check to see if you are logging any 404 messages on the tomcat side - i have found that memory and cpu idle time seem to dissappear with every 404 request passed over to tomcat from apache Sai. On Fri, 5 Sep 2003 12:09:52 -0500, Mike Curwen wrote > After about 15 emails, I'm gonna go back to the first: > > > I seemed to have read that java/tomcat isn't > > supposed to have memory leaks, > > AND > > > So where do I start looking for the problem? > > If I forget to close Statements would that cause the > > problem? > > So first of all, Java has built-in memory management and garbage > collection, so comparing against a language like C++, it's MUCH > harder to cause a memory leak in a Java program, *but not > impossible*. And up to now we're focusing on JDBC. Connection pools > and whether or not your driver strictly adheres to the JDBC standard > are certainly one source of memory leaks. But they're not the only > ones possible. What sorts of other activities are going on in your > application? Do you have other 3rd party libraries? Libraries > you've written yourself? Have these been profiled and exercised to > ensure they are not the ones leaking? > > > > -Original Message- > > From: Jim Lynch [mailto:[EMAIL PROTECTED] > > Sent: Friday, September 05, 2003 9:37 AM > > To: Tomcat Users List > > Subject: Re: Memory leaks? > > > > > > I'm most certain the connections are closed but there may be > > a few dangling statements. I'm using mysql jdbc. Not using > > pools since I never could get it working. Making direct requests. > > > > Still getting a out of memory hit every couple of days so I > > have to shutdown the server and start it up again. > > > > THnak,s > > Jim. > > > > "Shapira, Yoav" wrote: > > > > > > Howdy, > > > You don't have to close a result set if you're closing the > > statement > > > right away and the result set is the only one associated with the > > > statement... And in no case can closing the result set > > explicitly hurt > > > performance. > > > > > > Yoav Shapira > > > Millennium ChemInformatics > > > > > > >-Original Message- > > > >From: Greg Ward [mailto:[EMAIL PROTECTED] > > > >Sent: Thursday, September 04, 2003 10:05 AM > > > >To: Tomcat Users List; [EMAIL PROTECTED] > > > >Subject: Re: Memory leaks? > > > > > > > >On 03 September 2003, Jim Lynch said: > > > >> OK, that's probably what's going on. I know I should close > > > Statements > > > >> and Connections and do normally but I'm fairly certain I've some > > > >> out there dangling. I didn't know you had to close ResultSets, > > > >> however. Glad to know that. > > > > > > > >You don't have to close ResultSets -- check the JDBC docs: > > > > > > > > > > > > > http://java.sun.com/j2se/1.4.2/docs/api/java/s> > ql/Statement.html#close( > > > ) > > > > > > > >(Closing a Statement also closes any open ResultSets > > associated with > > > >that Statement.) > > > > > > > >Greg > > > > > > > > > >- > > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > This e-mail, including any attachments, is a confidential business > > > communication, and may contain information that is confidential, > > > proprietary and/or privileged. This e-mail is intended > > only for the > > > individual(s) to whom it is addressed, and may not be > > saved, copied, > > > printed, disclosed or used by anyone else. If you are not the(an) > > > intended recipient, please immediately delete this e-mail from your > > > computer system and notify the sender. Thank you. > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Open WebMail Project (http://openwebmail.org) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leaks
Howdy, Enable verbose GC (see Java VM Options for how to do this). Yoav Shapira Millennium ChemInformatics >-Original Message- >From: Christian Witucki [mailto:[EMAIL PROTECTED] >Sent: Wednesday, January 14, 2004 9:00 AM >To: [EMAIL PROTECTED] >Subject: Memory Leaks > >Does anyone know that when Garbage Collection is going on how often it >should be set to collect and if memory is really being returned. I believe >that the memory is not, but how can I check to determine that??? > >Christian Witucki >Network Analyst >375 Essjay Road >Williamsville, NY 14221 >716-631-3001 x3812 > >CONFIDENTIALITY NOTICE. This e-mail and attachments, if any, may contain >confidential information which is privileged and protected from disclosure >by Federal and State confidentiality laws, rules or regulations. This e- >mail and attachments, if any, are intended for the designated addressee >only . If you are not the designated addressee, you are hereby notified >that any disclosure, copying, or distribution of this e-mail and its >attachments, if any, may be unlawful and may subject you to legal >consequences. If you have received this e-mail and attachments in error, >please contact Independent Health immediately at (716) 631-3001 and delete >the e-mail and its attachments from your computer. Thank you for your >attention. > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leaks
I've been looking at this this week and have resolved that we need to buy a JVM Profiler, prob. JProfiler. -Original Message- From: Christian Witucki [mailto:[EMAIL PROTECTED] Sent: 14 January 2004 14:00 To: [EMAIL PROTECTED] Subject: Memory Leaks Does anyone know that when Garbage Collection is going on how often it should be set to collect and if memory is really being returned. I believe that the memory is not, but how can I check to determine that??? Christian Witucki Network Analyst 375 Essjay Road Williamsville, NY 14221 716-631-3001 x3812 CONFIDENTIALITY NOTICE. This e-mail and attachments, if any, may contain confidential information which is privileged and protected from disclosure by Federal and State confidentiality laws, rules or regulations. This e-mail and attachments, if any, are intended for the designated addressee only . If you are not the designated addressee, you are hereby notified that any disclosure, copying, or distribution of this e-mail and its attachments, if any, may be unlawful and may subject you to legal consequences. If you have received this e-mail and attachments in error, please contact Independent Health immediately at (716) 631-3001 and delete the e-mail and its attachments from your computer. Thank you for your attention. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- QAS Ltd. Developers of QuickAddress Software http://www.qas.com";>www.qas.com Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leaks
I have a problem with memory leak. You have see my message "BIG PROBLEM // LINUX TOMCAT SSL" ? -Message d'origine- De : Christian Witucki [mailto:[EMAIL PROTECTED] Envoyé : mercredi 14 janvier 2004 15:00 À : [EMAIL PROTECTED] Objet : Memory Leaks Does anyone know that when Garbage Collection is going on how often it should be set to collect and if memory is really being returned. I believe that the memory is not, but how can I check to determine that??? Christian Witucki Network Analyst 375 Essjay Road Williamsville, NY 14221 716-631-3001 x3812 CONFIDENTIALITY NOTICE. This e-mail and attachments, if any, may contain confidential information which is privileged and protected from disclosure by Federal and State confidentiality laws, rules or regulations. This e-mail and attachments, if any, are intended for the designated addressee only . If you are not the designated addressee, you are hereby notified that any disclosure, copying, or distribution of this e-mail and its attachments, if any, may be unlawful and may subject you to legal consequences. If you have received this e-mail and attachments in error, please contact Independent Health immediately at (716) 631-3001 and delete the e-mail and its attachments from your computer. Thank you for your attention. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.552 / Virus Database: 344 - Release Date: 15/12/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.552 / Virus Database: 344 - Release Date: 15/12/2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Leaks
My understanding is that the GC runs on a low-priority thread, so you never get to tell it when to run. The operating system and JVM deal with it. I also recall reading that memory is returned to the JVM, but not released back to the OS. So if you're watching Memory Usage in the Windows Task Manager and not seeing it go down, that might explain why. - MOD --- Christian Witucki <[EMAIL PROTECTED]> wrote: > Does anyone know that when Garbage Collection is > going on how often it should be set to collect and > if memory is really being returned. I believe that > the memory is not, but how can I check to determine > that??? > > Christian Witucki > Network Analyst > 375 Essjay Road > Williamsville, NY 14221 > 716-631-3001 x3812 > > CONFIDENTIALITY NOTICE. This e-mail and attachments, > if any, may contain confidential information which > is privileged and protected from disclosure by > Federal and State confidentiality laws, rules or > regulations. This e-mail and attachments, if any, > are intended for the designated addressee only . If > you are not the designated addressee, you are hereby > notified that any disclosure, copying, or > distribution of this e-mail and its attachments, if > any, may be unlawful and may subject you to legal > consequences. If you have received this e-mail and > attachments in error, please contact Independent > Health immediately at (716) 631-3001 and delete the > e-mail and its attachments from your computer. > Thank you for your attention. > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leaks
Hi There, You can invoke the garbage collector by using the System.gc() method. The memory is never returned to OS but the JVM keeps it in a pool used for object creation, it would make no sense in releasing this back to the OS as it will probably need to use it at some point or another. In more recent JVM's (1.4 onwards) the garbage collector has been threaded to improve performance and penalties as until then the cost of a collection was relatively expensive. For more information read the documentation at www.java.sun.com Hope this helps Pete -Original Message- From: Michael Duffy [mailto:[EMAIL PROTECTED] Sent: 14 January 2004 14:07 To: Tomcat Users List Subject: Re: Memory Leaks My understanding is that the GC runs on a low-priority thread, so you never get to tell it when to run. The operating system and JVM deal with it. I also recall reading that memory is returned to the JVM, but not released back to the OS. So if you're watching Memory Usage in the Windows Task Manager and not seeing it go down, that might explain why. - MOD --- Christian Witucki <[EMAIL PROTECTED]> wrote: > Does anyone know that when Garbage Collection is > going on how often it should be set to collect and > if memory is really being returned. I believe that > the memory is not, but how can I check to determine > that??? > > Christian Witucki > Network Analyst > 375 Essjay Road > Williamsville, NY 14221 > 716-631-3001 x3812 > > CONFIDENTIALITY NOTICE. This e-mail and attachments, > if any, may contain confidential information which > is privileged and protected from disclosure by > Federal and State confidentiality laws, rules or > regulations. This e-mail and attachments, if any, > are intended for the designated addressee only . If > you are not the designated addressee, you are hereby > notified that any disclosure, copying, or > distribution of this e-mail and its attachments, if > any, may be unlawful and may subject you to legal > consequences. If you have received this e-mail and > attachments in error, please contact Independent > Health immediately at (716) 631-3001 and delete the > e-mail and its attachments from your computer. > Thank you for your attention. > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leaks
Howdy, Just one correction: > You can invoke the garbage collector by using the System.gc() method. This is a common misconception: System.gc() is merely a suggestion to the VM to run collection. The VM is not obliged to run it then, i.e. this is not a hard directive. It should never be relied upon. With JDK 1.4, there's a runtime parameter to ignore System.gc() calls and that parameter may be on by default in the future. Yoav Shapira > >The memory is never returned to OS but the JVM keeps it in a pool used for >object creation, it would make no sense in releasing this back to the OS as >it will probably need to use it at some point or another. > >In more recent JVM's (1.4 onwards) the garbage collector has been threaded >to improve performance and penalties as until then the cost of a collection >was relatively expensive. > >For more information read the documentation at www.java.sun.com > >Hope this helps > >Pete > >-Original Message- >From: Michael Duffy [mailto:[EMAIL PROTECTED] >Sent: 14 January 2004 14:07 >To: Tomcat Users List >Subject: Re: Memory Leaks > > > >My understanding is that the GC runs on a low-priority >thread, so you never get to tell it when to run. The >operating system and JVM deal with it. > >I also recall reading that memory is returned to the >JVM, but not released back to the OS. So if you're >watching Memory Usage in the Windows Task Manager and >not seeing it go down, that might explain why. - MOD > > > > >--- Christian Witucki <[EMAIL PROTECTED]> >wrote: >> Does anyone know that when Garbage Collection is >> going on how often it should be set to collect and >> if memory is really being returned. I believe that >> the memory is not, but how can I check to determine >> that??? >> >> Christian Witucki >> Network Analyst >> 375 Essjay Road >> Williamsville, NY 14221 >> 716-631-3001 x3812 >> >> CONFIDENTIALITY NOTICE. This e-mail and attachments, >> if any, may contain confidential information which >> is privileged and protected from disclosure by >> Federal and State confidentiality laws, rules or >> regulations. This e-mail and attachments, if any, >> are intended for the designated addressee only . If >> you are not the designated addressee, you are hereby >> notified that any disclosure, copying, or >> distribution of this e-mail and its attachments, if >> any, may be unlawful and may subject you to legal >> consequences. If you have received this e-mail and >> attachments in error, please contact Independent >> Health immediately at (716) 631-3001 and delete the >> e-mail and its attachments from your computer. >> Thank you for your attention. >> >> >> >- >> To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> For additional commands, e-mail: >> [EMAIL PROTECTED] >> > > >__ >Do you Yahoo!? >Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes >http://hotjobs.sweepstakes.yahoo.com/signingbonus > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Leaks
Hi! Shapira, Yoav wrote: This is a common misconception: System.gc() is merely a suggestion to the VM to run collection. The VM is not obliged to run it then, i.e. this is not a hard directive. It should never be relied upon. With JDK 1.4, there's a runtime parameter to ignore System.gc() calls and that parameter may be on by default in the future. Also, calling System.gc() is unnecessary in allmost all cases it is used. The VM does a far better job in determining when the gc should run than most programmers could. Only if you know your way around in the internals of the VM and you know that it will not run a gc cycle that would beneficial, you can call System.gc() to politely ask the VM to do so. Still no garantees, though. In any case, although a call to System.cg() will most likely no hurt your performance, you should never ever rely on it. Phil -- And on the seventh day, He exited from append mode. (Book of create(2), line 255) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leaks
In general true and that's what the spec says, but we had once following experience with a version of a jvm (can't recall which): The vm was not able to perform the gc if an out of memory occured, even if enough free objects where there to free quite some memory. (Obviously the gc didn't start at a treshhold but only when the memory was full, and couldn't get the memory it needed to perform the task) The problem vanished when we started to call gc() on a regular base. the call to gc() had some effect. (Runtime.freeMemory() grew after each call to gc()) This indicated, that (with that specific vm) the call to gc() did something. > -Original Message- > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 14, 2004 3:43 PM > To: Tomcat Users List > Subject: RE: Memory Leaks > > > This is a common misconception: System.gc() is merely a suggestion to > the VM to run collection. The VM is not obliged to run it then, i.e. > this is not a hard directive. It should never be relied > upon. With JDK > 1.4, there's a runtime parameter to ignore System.gc() calls and that > parameter may be on by default in the future. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Leaks
Yoav, > With JDK 1.4, there's a runtime parameter to ignore System.gc() calls and that parameter may be on by default in the future. What is this parameter? I've never seen it before... -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leaks
Howdy, > > With JDK >> 1.4, there's a runtime parameter to ignore System.gc() calls and that >> parameter may be on by default in the future. > >What is this parameter? I've never seen it before... > >-chris -XX:+DisableExplicitGC is the parameter, which I believe has been available since JDK 1.4.0. Yoav Shapria This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Leaks
Yoav, With JDK 1.4, there's a runtime parameter to ignore System.gc() calls and that parameter may be on by default in the future. What is this parameter? I've never seen it before... -XX:+DisableExplicitGC is the parameter, which I believe has been available since JDK 1.4.0. Wow, I didn't know that -XX parameters existed. Where can I get more information on these, if you don't mind? Thanks, -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leaks
http://java.sun.com/docs/hotspot/VMOptions.html > -Original Message- > From: Christopher Schultz [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 14, 2004 4:17 PM > To: Tomcat Users List > Subject: Re: Memory Leaks > > > > Wow, I didn't know that -XX parameters existed. Where can I get more > information on these, if you don't mind? > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Vedr.: Re: Memory Leaks
Hey Chris,
sorry for interrupting but if you into optimizing your JVM setting as well
as explorings its options I would recommend:
-
http://developers.sun.com/techtopics/mobility/midp/articles/garbagecollection2/
- http://java.sun.com/docs/hotspot/gc1.4.2/
Perhaps some of the more savvy developers can give more directions.
As always remember the best tests are those carried out by yourself
profiling you applications - if I didnt say SOMEONE else would have...
;-)
Christopher Schultz <[EMAIL PROTECTED]>
14-01-2004 16:17
Besvar venligst til "Tomcat Users List"
Til:Tomcat Users List <[EMAIL PROTECTED]>
cc:
Vedr.: Re: Memory Leaks
Yoav,
>>>With JDK
>>>1.4, there's a runtime parameter to ignore System.gc() calls and that
>>>parameter may be on by default in the future.
>>
>>What is this parameter? I've never seen it before...
>
> -XX:+DisableExplicitGC is the parameter, which I believe has been
> available since JDK 1.4.0.
Wow, I didn't know that -XX parameters existed. Where can I get more
information on these, if you don't mind?
Thanks,
-chris
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
___
Vi goer opmaerksom paa, at denne e-mail kan indeholde fortrolig information. Hvis du
ved en fejltagelse modtager e-mailen, beder vi dig venligst informere afsender om
fejlen ved at bruge svar-funktionen. Samtidig beder vi dig slette e-mailen i dit
system uden at videresende eller kopiere den.
Selv om e-mailen og ethvert vedhaeftet bilag efter vores overbevisning er fri for
virus og andre fejl, som kan paavirke computeren eller it-systemet, hvori den modtages
og laeses, aabnes den paa modtagerens eget ansvar. Vi paatager os ikke noget ansvar
for tab og skade, som er opstaaet i forbindelse med at modtage og bruge e-mailen.
___
Please note that this message may contain confidential information. If you have
received this message by mistake, please inform the sender of the mistake by sending a
reply, then delete the message from your system without making, distributing or
retaining any copies of it.
Although we believe that the message and any attachments are free from viruses and
other errors that might affect the computer or IT system where it is received and
read, the recipient opens the message at his or her own risk. We assume no
responsibility for any loss or damage arising from the receipt or use of this message.
Re: Vedr.: Re: Memory Leaks
Thomas, sorry for interrupting but if you into optimizing your JVM setting as well as explorings its options I would recommend: Perhaps some of the more savvy developers can give more directions. Thanks for the pointers. Actually, I'm not having any performance problems at the moment :) As always remember the best tests are those carried out by yourself profiling you applications - if I didnt say SOMEONE else would have... I've been running OptimizeIt and Tomcat together and quite a while. You don't need to convince me! -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: memory-leaks in servlets, tool for tracing ?
Howdy, I like OptimizeIt's heap snapshots. Yoav Shapira Millennium ChemInformatics >-Original Message- >From: Dirk Griesbach [mailto:[EMAIL PROTECTED] >Sent: Wednesday, October 29, 2003 4:03 AM >To: Tomcat Users List >Subject: memory-leaks in servlets, tool for tracing ? > >hi everybody, > >our TC-based webapplication performs well but the java-processes concerned >are showing increasing memory usage over time. For tracing we already >stripped the app down to the very basic to get a clue. Wasn't successful >enough. > >Does anybody's got experience with a profiling toolkit which she/he can >suggest ? > >grisi This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: memory-leaks in servlets, tool for tracing ?
Grisi, our TC-based webapplication performs well but the java-processes concerned are showing increasing memory usage over time. For tracing we already stripped the app down to the very basic to get a clue. Wasn't successful enough. Have you looked at the memory over a long time, including several large GCs? I've had to do this in the past, and it's no fun without a profiler. Unfortunately, profiling tools can get expensive. Anyone know of any decent OSS ones out there? When I've done this sans profiler in the past, I did two things: 1. Turn on verbose GC for the VM (dumps GC stats to stdout) 2. Write a program to parse the GC lines and graph them over time We got a curve that looked like this: <- max memory /\ / used memory-/\ / \___/ /\ / \___/ / \___/ --/ ^ OutOfMemoryError This indicated that we were really screwing up somewhere. Had the curve looked like this, we would be happy: <- max memory /\ /\ /\ / \ / \ / \ /\ /\ /\ / \_/ \_/ \ _/ ... or even with high-frequency perturbations in there (usually from minor GCs happening periodically). It often helps to set the initial heap size and the maximum heap size to the same value (usually something like 256MB, 512MB, or 1024MB). Just remember that the higher it is, the longer you'll have to wait for a full GC. GCs don't always free everything they can. If they did, they'd take forever. It's only when the VM gets near its maximum heap size that the GC panics and goes on a collection rampage. If you ever get an OutOfMemoryError, go and get a thread-dump. On UNIX, you can sent the VM a STOP signal using kill or by pressing CTRL-\ if the VM is running in a terminal. You'll get lots of good information including the number of threads and where they are. You might find that there are threads there that you thought had terminated long ago. Old active threads are always a source of tied-up memory. Does anybody's got experience with a profiling toolkit which she/he can suggest ? I have some experience with Borland's OptimizeIt, and I've even recently installed it on Linux and run Tomcat 4.1 through it. I was able to determine something about the VM and Tomcat that might help you. I thought I had a memory leak, too. It turns out that when you recompile your servlets and Tomcat does an auto-reload (I have it configured that way), a new ClassLoader gets installed to hold the classes loaded for the new context. However, the classes loaded from the old context stick around because the JVM doesn't want to discard java.lang.Class objects in case they're useful in the future. This increases the number of java.lang.Class objects by about 600 every time I recompiled. After many compile-deploy-reload cycles, my VM was hogging all my memory and lots of CPU. Perhaps this is your problem, too? -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: memory-leaks in servlets, tool for tracing ?
Christopher, thanks for your comprehensive response ! See more comments down ... - Original Message - From: Christopher Schultz <[EMAIL PROTECTED]> To: Tomcat Users List <[EMAIL PROTECTED]> Sent: Wednesday, October 29, 2003 3:29 PM Subject: Re: memory-leaks in servlets, tool for tracing ? > Grisi, > > > our TC-based webapplication performs well but the java-processes > > concerned are showing increasing memory usage over time. For tracing > > we already stripped the app down to the very basic to get a clue. > > Wasn't successful enough. > > Have you looked at the memory over a long time, including several large > GCs? I've had to do this in the past, and it's no fun without a > profiler. No, it isn't indeed. I've been checking LINUX' 'top' over a period of time. A mem-hole is apparent. Unfortunately our app makes use of a (self-developed) JNI-Module (C) which makes it even more difficult because the C-code also runs in the Java-context. Unfortunately, profiling tools can get expensive. Anyone know > of any decent OSS ones out there? 'JProbe' and 'OptimizeIt!' are really no bargains ! > > When I've done this sans profiler in the past, I did two things: > > 1. Turn on verbose GC for the VM (dumps GC stats to stdout) > 2. Write a program to parse the GC lines and graph them over time > > We got a curve that looked like this: > > <- max memory > /\ / > used memory-/\ / \___/ > /\ / \___/ > / \___/ > --/ ^ OutOfMemoryError > > This indicated that we were really screwing up somewhere. > > Had the curve looked like this, we would be happy: > > <- max memory > /\ /\ /\ > / \ / \ / \ > /\ /\ /\ >/ \_/ \_/ \ > _/ > > > ... or even with high-frequency perturbations in there (usually from > minor GCs happening periodically). > > It often helps to set the initial heap size and the maximum heap size to > the same value (usually something like 256MB, 512MB, or 1024MB). Just > remember that the higher it is, the longer you'll have to wait for a > full GC. > > GCs don't always free everything they can. If they did, they'd take > forever. It's only when the VM gets near its maximum heap size that the > GC panics and goes on a collection rampage. > > If you ever get an OutOfMemoryError, go and get a thread-dump. On UNIX, > you can sent the VM a STOP signal using kill or by pressing CTRL-\ if > the VM is running in a terminal. Good idea, I also achieved this by narrowing available mem on the machine until java gave up quitting with an 'out-of-mem' err. The problem is that the dump written only contains the hex-adresses of the modules being involved. No possibilty to trace those adressesdown to the functions or even modules involved. Even more difficult: the root cause given by this dump is not the function(s)/method(s) causing the memory problems. > > You'll get lots of good information including the number of threads and > where they are. You might find that there are threads there that you > thought had terminated long ago. Old active threads are always a source > of tied-up memory. > > > Does anybody's got experience with a profiling toolkit which she/he > > can suggest ? There is a tool provided by SUN itself called 'HAT' (HeapAnalyzingTool) http://java.sun.com/people/billf/heap/ but this seems to be only applicable to java programs, not servlets. With Tomcat there were errors. May be in different cases this would help. > > I have some experience with Borland's OptimizeIt, and I've even recently > installed it on Linux and run Tomcat 4.1 through it. I was able to > determine something about the VM and Tomcat that might help you. I > thought I had a memory leak, too. In our case it was helpful to operate java with the -Xincgc option that causes the GC to collect smaller amounts of mem; but does this more often. It gives a more accurate impression in the current memory status. What we did is the following: - separate the JNI-module and write a little main()-frame around it to run it alone. - compile this with the 'dmalloc'-library to identify mem not being free'd there. - running the Servlet in one scenario (without JNI) and examine the few methods being touched. - rewrite java-code being in question. - test it on mem-behavior. - iterate with the next scenario etc. Could be more satisfying, this kind of work, but it should be straight-forward. > It turns out that when you recompile your servlets and Tomcat does an > auto-reload (
Re: memory-leaks in servlets, tool for tracing ?
Grisi, our TC-based webapplication performs well but the java-processes concerned are showing increasing memory usage over time. For tracing we already stripped the app down to the very basic to get a clue. Wasn't successful enough. Have you looked at the memory over a long time, including several large GCs? I've had to do this in the past, and it's no fun without a profiler. No, it isn't indeed. I've been checking LINUX' 'top' over a period of time. A mem-hole is apparent. Unfortunately our app makes use of a (self-developed) JNI-Module (C) which makes it even more difficult because the C-code also runs in the Java-context. Ooh, JNI is always a wild-card. I wrote some JNI code that we were using within a servlet container as well. I tested the hell out of it, especially with threaded use (that's very important). I could only get it to fail when it had trouble writing to files at very high thread rates (I made each thread write to files on a floppy disk, which would run out of space and cause an I/O error). I'd highly recommend testing your native library separately from the use of JNI and the servlet. Try setting up a test harness for the native code to see if there are easier memory leaks to find. Adding JNI and the VM on top of all that it tough. Some profiles claim to allow you to watch native code as well as Java code (which sounds really cool!), but again they are expensive. You can use gdb and clever use of tests that are likely to break your code without getting Java involved. Unfortunately, profiling tools can get expensive. Anyone know of any decent OSS ones out there? I don't. Anyone have any ideas? Some intern at my old company wrote one from scratch, apparently, so I'm guessing they aren't TOO hard. He used the JVMDP or whatever, which is a debugging protocol that you use to attach to a running VM process. 'JProbe' and 'OptimizeIt!' are really no bargains ! Well, that depends on how much money you are going to spend to find the problem otherwise. How much do you (and your team) cost per hour to your employer? If it's going to take you a week (40 hours * x team members), then how does that compare to the cost of an OptimizeIt license...? The problem is that the [thread] dump written only contains the hex-adresses of the modules being involved. No possibilty to trace those adressesdown to the functions or even modules involved. Yeah, that's a problem. You'd have to do a lot of investigation to figure out what's actually being executed. Even more difficult: the root cause given by this dump is not the function(s)/method(s) causing the memory problems. Well, once you get an OutOfMemoryException, you pretty much can't trust anything the VM says after that. What you're seeing is just a guide; they might be total lies. :) There is a tool provided by SUN itself called 'HAT' (HeapAnalyzingTool) http://java.sun.com/people/billf/heap/ but this seems to be only applicable to java programs, not servlets. With Tomcat there were errors. May be in different cases this would help. Well, Tomcat is a Java program, so you should be able to use it, right? It's just a matter of figuring out how to hook it into your startup process. I hacked through the OptimizeIt instructions and created an ant target to start my Tomcat instance running inside of OptimizeIt. Very sexy. In our case it was helpful to operate java with the -Xincgc option that causes the GC to collect smaller amounts of mem; but does this more often. It gives a more accurate impression in the current memory status. What we did is the following: - separate the JNI-module and write a little main()-frame around it to run it alone. - compile this with the 'dmalloc'-library to identify mem not being free'd there. - running the Servlet in one scenario (without JNI) and examine the few methods being touched. - rewrite java-code being in question. - test it on mem-behavior. - iterate with the next scenario etc. Could be more satisfying, this kind of work, but it should be straight-forward. Well, that's the approach I'd take without a profiler. Good luck. Let us know what you find. -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: memory-leaks in servlets, tool for tracing ?
Howdy, our TC-based webapplication performs well but the java-processes concerned are showing increasing memory usage over time. For tracing This basic idea that memory usage should be constant over time is very common and usually wrong. The JVM will use as much memory as it needs without GC'ing until it has to. So if you give it 1GB for an app that needs 10MB, and keep that app running for long, you'd see memory usage increasing and increasing until GC is fired. Even then, the heap will stay where it was, only the %free will be much higher. The better solution here is not to give your app so much memory, make GC run more often, and track the %free instead of just total process image memory via the top command. You need to find it if there are memory leaks, of if the memory increase is legitimate, e.g. due to high usage. >I'd highly recommend testing your native library separately from the use That's a very good suggestion. >> Unfortunately, profiling tools can get expensive. Anyone know >>of any decent OSS ones out there? The question comes up every couple of months on this list, search the archives. Personally, I think OptimizeIt is worth its price without a doubt. >I don't. Anyone have any ideas? Some intern at my old company wrote one >from scratch, apparently, so I'm guessing they aren't TOO hard. He used >the JVMDP or whatever, which is a debugging protocol that you use to >attach to a running VM process. It's easy to write bad profilers, each EXTREMELY difficult to write profilers with low overhead. It's the JVMPI (Java Virtual Machine Profiling Interface) that you must implement. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: memory-leaks in servlets, tool for tracing ?
Yoav, You make a great point about how the app should stabilize it's memory usage over time. However, I've got a question about memory usage when I stop (via Tomcat manager) and reload a webapp via a WAR file. If I understand your point, and I'm close to the max heap size, shouldn't GC free up the memory from the old webapp? In my case, GC happens more frequently, but doesn't do a great job (not even close to freeing up the memory footprint of my webapp). Eventually, I run into out of memory problems. Shouldn't a reload of a webapp cause a relase of the resources from the old webapp? -Anthony Carlos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: memory-leaks in servlets, tool for tracing ?
Howdy, >You make a great point about how the app should stabilize it's memory >usage over time. However, I've got a question about memory usage when I >stop (via Tomcat manager) and reload a webapp via a WAR file. If I >understand your point, and I'm close to the max heap size, shouldn't GC >free up the memory from the old webapp? In my case, GC happens more >frequently, but doesn't do a great job (not even close to freeing up >the memory footprint of my webapp). Eventually, I run into out of >memory problems. Shouldn't a reload of a webapp cause a relase of the >resources from the old webapp? A reload should release old resources when you restart the webapp, yes. But it's your responsibility to ensure there's nothing in your application which would stay in memory after a webapp restart. For example, classes in common/lib aren't affected by a restart, so if you app puts stuff there, and then you restart your app, the stuff you put in common/lib will still be there. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : memory-leaks in servlets, tool for tracing ?
What about classes with static method and/or static attributes ? Are they deleted from the old webapp ? -Message d'origine- De : Shapira, Yoav [mailto:[EMAIL PROTECTED] Envoyé : mercredi 5 novembre 2003 15:57 À : Tomcat Users List Objet : RE: memory-leaks in servlets, tool for tracing ? Howdy, >You make a great point about how the app should stabilize it's memory >usage over time. However, I've got a question about memory usage when I >stop (via Tomcat manager) and reload a webapp via a WAR file. If I >understand your point, and I'm close to the max heap size, shouldn't GC >free up the memory from the old webapp? In my case, GC happens more >frequently, but doesn't do a great job (not even close to freeing up >the memory footprint of my webapp). Eventually, I run into out of >memory problems. Shouldn't a reload of a webapp cause a relase of the >resources from the old webapp? A reload should release old resources when you restart the webapp, yes. But it's your responsibility to ensure there's nothing in your application which would stay in memory after a webapp restart. For example, classes in common/lib aren't affected by a restart, so if you app puts stuff there, and then you restart your app, the stuff you put in common/lib will still be there. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : RE : memory-leaks in servlets, tool for tracing ?
It would be good if some of you writes an kind of howTo that shows : - a webapp with a memory leak. - the use of a profiler program ( with screenshots ) to detect the memory leak. -Message d'origine- De : Laurent Michenaud Envoyé : mercredi 5 novembre 2003 16:56 À : Tomcat Users List Objet : RE : memory-leaks in servlets, tool for tracing ? What about classes with static method and/or static attributes ? Are they deleted from the old webapp ? -Message d'origine- De : Shapira, Yoav [mailto:[EMAIL PROTECTED] Envoyé : mercredi 5 novembre 2003 15:57 À : Tomcat Users List Objet : RE: memory-leaks in servlets, tool for tracing ? Howdy, >You make a great point about how the app should stabilize it's memory >usage over time. However, I've got a question about memory usage when I >stop (via Tomcat manager) and reload a webapp via a WAR file. If I >understand your point, and I'm close to the max heap size, shouldn't GC >free up the memory from the old webapp? In my case, GC happens more >frequently, but doesn't do a great job (not even close to freeing up >the memory footprint of my webapp). Eventually, I run into out of >memory problems. Shouldn't a reload of a webapp cause a relase of the >resources from the old webapp? A reload should release old resources when you restart the webapp, yes. But it's your responsibility to ensure there's nothing in your application which would stay in memory after a webapp restart. For example, classes in common/lib aren't affected by a restart, so if you app puts stuff there, and then you restart your app, the stuff you put in common/lib will still be there. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : memory-leaks in servlets, tool for tracing ?
Laurent, What about classes with static method and/or static attributes ? Are they deleted from the old webapp ? I don't believe that the VM ever releases resources taken up by Class objects (I think this includes static resources for a class). There used to be a VM option, -noclassgc, that was often used so that instance-less Classes wouldn't get GC'd. Almost everyone who ran Java apps turned that option on. I'm not even sure if that option is still available. They may have simply eliminated the GC'ing of Class objects altogether. I know that in my stock tc 4.1.27 on Sun's 1.4.2 VM, that after a re-load, all the old Class objects stick around. It's quite disconcerting because the heap grows by around 600 classes every time a context-reload occurs. The solution, of course, is not to enable context-reloading on production :) -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : RE : memory-leaks in servlets, tool for tracing ?
When does a class reload occur ? When u update a JSP ? When u update a class ? When u update a lib ? When u do reload in the manager webapps ? => yes :) Anything else ? -Message d'origine- De : Christopher Schultz [mailto:[EMAIL PROTECTED] Envoyé : mercredi 5 novembre 2003 23:31 À : Tomcat Users List Objet : Re: RE : memory-leaks in servlets, tool for tracing ? Laurent, > What about classes with static method and/or static attributes ? > > Are they deleted from the old webapp ? I don't believe that the VM ever releases resources taken up by Class objects (I think this includes static resources for a class). There used to be a VM option, -noclassgc, that was often used so that instance-less Classes wouldn't get GC'd. Almost everyone who ran Java apps turned that option on. I'm not even sure if that option is still available. They may have simply eliminated the GC'ing of Class objects altogether. I know that in my stock tc 4.1.27 on Sun's 1.4.2 VM, that after a re-load, all the old Class objects stick around. It's quite disconcerting because the heap grows by around 600 classes every time a context-reload occurs. The solution, of course, is not to enable context-reloading on production :) -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE : memory-leaks in servlets, tool for tracing ?
Howdy, >context-reload occurs. The solution, of course, is not to enable >context-reloading on production :) This is very good advice. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE : RE : memory-leaks in servlets, tool for tracing ?
Howdy, That'd be good, and I think there are some efforts in this area. (Is Peter Lin's apache performance book available for online purchase?) You can google for them. Another one with a specific app is a good idea, but requires a lot of time ;) Yoav Shapira Millennium ChemInformatics >-Original Message- >From: Laurent Michenaud [mailto:[EMAIL PROTECTED] >Sent: Wednesday, November 05, 2003 10:59 AM >To: Tomcat Users List >Subject: RE : RE : memory-leaks in servlets, tool for tracing ? > >It would be good if some of you writes an kind of howTo >that shows : >- a webapp with a memory leak. >- the use of a profiler program ( with screenshots ) to detect the memory >leak. > >-Message d'origine- >De : Laurent Michenaud >Envoyé : mercredi 5 novembre 2003 16:56 >À : Tomcat Users List >Objet : RE : memory-leaks in servlets, tool for tracing ? > >What about classes with static method and/or static attributes ? > >Are they deleted from the old webapp ? > >-Message d'origine- >De : Shapira, Yoav [mailto:[EMAIL PROTECTED] >Envoyé : mercredi 5 novembre 2003 15:57 >À : Tomcat Users List >Objet : RE: memory-leaks in servlets, tool for tracing ? > > >Howdy, > >>You make a great point about how the app should stabilize it's memory >>usage over time. However, I've got a question about memory usage when I >>stop (via Tomcat manager) and reload a webapp via a WAR file. If I >>understand your point, and I'm close to the max heap size, shouldn't GC >>free up the memory from the old webapp? In my case, GC happens more >>frequently, but doesn't do a great job (not even close to freeing up >>the memory footprint of my webapp). Eventually, I run into out of >>memory problems. Shouldn't a reload of a webapp cause a relase of the >>resources from the old webapp? > >A reload should release old resources when you restart the webapp, yes. >But it's your responsibility to ensure there's nothing in your >application which would stay in memory after a webapp restart. For >example, classes in common/lib aren't affected by a restart, so if you >app puts stuff there, and then you restart your app, the stuff you put >in common/lib will still be there. > >Yoav Shapira > > > >This e-mail, including any attachments, is a confidential business >communication, and may contain information that is confidential, >proprietary and/or privileged. This e-mail is intended only for the >individual(s) to whom it is addressed, and may not be saved, copied, >printed, disclosed or used by anyone else. If you are not the(an) intended >recipient, please immediately delete this e-mail from your computer system >and notify the sender. Thank you. > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : RE : memory-leaks in servlets, tool for tracing ?
Laurent, When does a class reload occur ? I was talking about a context re-load, which dumps everything in the context and re-starts it in a new ClassLoader. When u update a JSP ? Yes, the class gets re-loaded, but not the whole context. This is much less of a problem. When u update a class ? Sometimes is depende on the class you update. If you update a servlet that's mapped in web.xml, then Tomcat will definately re-load the context. Sometimes it seems like if I update a bean class that Tomcat doesn't re-load. I don't know it's checking technique. When u update a lib ? I don't think it re-loads the context for a lib update. When u do reload in the manager webapps ? => yes :) Of course! It will also re-load if web.xml changes, and I've seen it re-load sometimes if anything directly in the WEB-INF directory changes (i.e. I have struts-config.xml in my current application, and if I change that, sometimes it reloads). -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
