Discussion:
Memory leaks?
Jim Lynch
2003-09-03 16:56:33 UTC
Permalink
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(ApplicationFilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)

(Big snip)

org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java: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.
Richard Hill
2003-09-03 17:40:27 UTC
Permalink
Try passing the jvm the -server option

-----Original Message-----
From: Jim Lynch [mailto:***@sgi.com]
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: tomcat-user-***@jakarta.apache.org
For additional commands, e-mail: tomcat-user-***@jakarta.apache.org
Paul
2003-09-03 19:27:48 UTC
Permalink
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" <***@sgi.com>
To: "tomcat" <tomcat-***@jakarta.apache.org>
Sent: Wednesday, September 03, 2003 12:56 PM
Subject: Memory leaks?
Post by Jim Lynch
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
javax.servlet.ServletException: Servlet execution threw an exception
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:269)
Post by Jim Lynch
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
Post by Jim Lynch
(Big snip)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:392)
Post by Jim Lynch
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:619)
Post by Jim Lynch
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.
---------------------------------------------------------------------
Jim Lynch
2003-09-03 20:05:28 UTC
Permalink
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.
Post by Paul
Docs indicate that leaving a stmt or rs object open can cause memory leaks.
Here is an example of properly written code to use a db connection obtained
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 -----
Sent: Wednesday, September 03, 2003 12:56 PM
Subject: Memory leaks?
Post by Jim Lynch
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
javax.servlet.ServletException: Servlet execution threw an exception
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:269)
Post by Jim Lynch
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
Post by Jim Lynch
(Big snip)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:392)
Post by Jim Lynch
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:619)
Post by Jim Lynch
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.
---------------------------------------------------------------------
---------------------------------------------------------------------
Greg Ward
2003-09-04 14:04:39 UTC
Permalink
Post by Jim Lynch
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
Mike Curwen
2003-09-03 20:07:35 UTC
Permalink
I'm not sure I'm configuring things quite correctly, because it seems to
me I should be able to do this with one less token...

Apache 2
TC 4.1.24
JK

My workers.properties:
worker.list=tomcat1
worker.tomcat1.port=11009
worker.tomcat1.host=localhost
worker.tomcat1.type=ajp13


I define an Apache Virtual Host in httpd.conf:
<VirtualHost xxx.xxx.xxx.xxx>
JKMount /ATM tomcat1
JKMount /ATM/* tomcat1
DocumentRoot /home/webhome/atm/htdocs/
ServerName www.foo.com
ServerAlias foo.com
ErrorLog /var/log/atm/error_log
CustomLog /var/log/atm/access_log combined
</VirtualHost>

And in Tomcat server.xml:
(inside the localhost 'host' element)

<Context path="/ATM"
docBase="/home/webhome/atm/"
defaultSessionTimeOut="60"
reloadable="true" >
</Context>


So now to access regular static pages with apache, I just say:
http://www.foo.com/xyz.html
http://www.foo.com/pages/morepages/foo.html

And to do servlet/jsp stuff:
http://www.foo.com/ATM/servletFoo
http://www.foo.com/ATM/foo.jsp
http://www.foo.com/ATM/administer/admin.jsp

This works fairly well, I suppose, but what about sites where MOST
content is jsp/servlet based?

I'd like my URLS to not require the /ATM token.

So then I thought to do this (in apache):
<VirtualHost xxx.xxx.xxx.xxx>
JKMount /*.jsp tomcat1
JKMount /*/*.jsp tomcat1
JKMount /servletFoo tomcat1
DocumentRoot /home/webhome/atm/htdocs/
ServerName www.foo.com
ServerAlias foo.com
ErrorLog /var/log/atm/error_log
CustomLog /var/log/atm/access_log combined
</VirtualHost>

But.... how do I match up the requests from apache's virtual host
www.foo.com to the /ATM context in Tomcat? Am I looking at creating a
new <Host> in Tomcat for each <VirtualHost> in apache?

And then the default webapp for each of my TC Hosts would be the /ATM
application?

Thanks for any pointers.
John Turner
2003-09-03 20:28:06 UTC
Permalink
Post by Mike Curwen
<VirtualHost xxx.xxx.xxx.xxx>
JKMount /ATM tomcat1
JKMount /ATM/* tomcat1
I wouldn't do /ATM without a wildcard or something after it.
Post by Mike Curwen
DocumentRoot /home/webhome/atm/htdocs/
ServerName www.foo.com
ServerAlias foo.com
ErrorLog /var/log/atm/error_log
CustomLog /var/log/atm/access_log combined
</VirtualHost>
(inside the localhost 'host' element)
<Context path="/ATM"
docBase="/home/webhome/atm/"
defaultSessionTimeOut="60"
reloadable="true" >
</Context>
http://www.foo.com/xyz.html
http://www.foo.com/pages/morepages/foo.html
http://www.foo.com/ATM/servletFoo
http://www.foo.com/ATM/foo.jsp
http://www.foo.com/ATM/administer/admin.jsp
This works fairly well, I suppose, but what about sites where MOST
content is jsp/servlet based?
I'd like my URLS to not require the /ATM token.
You don't need it.
Post by Mike Curwen
<VirtualHost xxx.xxx.xxx.xxx>
JKMount /*.jsp tomcat1
JKMount /*/*.jsp tomcat1
JKMount /servletFoo tomcat1
DocumentRoot /home/webhome/atm/htdocs/
ServerName www.foo.com
ServerAlias foo.com
ErrorLog /var/log/atm/error_log
CustomLog /var/log/atm/access_log combined
</VirtualHost>
Double wildcards is "illegal". "/*.jsp" is equivalent to "/*/*.jsp"
since the second "/" is covered by the "*" in "/*.jsp".
Post by Mike Curwen
But.... how do I match up the requests from apache's virtual host
www.foo.com to the /ATM context in Tomcat? Am I looking at creating a
new <Host> in Tomcat for each <VirtualHost> in apache?
Yes.
Post by Mike Curwen
And then the default webapp for each of my TC Hosts would be the /ATM
application?
You mean sharing Contexts across Hosts? I don't think so.

Your Context path is just "" with the same docBase. Then your JkMounts are:

JkMount /*.jsp worker-name
JkMount /something-typically-servlet/* ajp13

John
Mike Curwen
2003-09-03 21:15:55 UTC
Permalink
inlined replies...
Post by Richard Hill
-----Original Message-----
Sent: Wednesday, September 03, 2003 3:28 PM
To: Tomcat Users List
Subject: Re: JKMount, virtual hosts, and avoiding the webapp name
<snip />
Post by Richard Hill
Post by Mike Curwen
But.... how do I match up the requests from apache's virtual host
www.foo.com to the /ATM context in Tomcat? Am I looking at
creating a
Post by Mike Curwen
new <Host> in Tomcat for each <VirtualHost> in apache?
Yes.
Post by Mike Curwen
And then the default webapp for each of my TC Hosts would
be the /ATM
Post by Mike Curwen
application?
You mean sharing Contexts across Hosts? I don't think so.
Oops, I mispoke. We have a single application that we deploy multiple
contexts of, so that each virtual host has its own copy of the
application. So in my 'new' scheme, I'd specify that the default webapp
is this 'common' application, but not 'shared' in the sense you thought,
(because of my typing).
Post by Richard Hill
Your Context path is just "" with the same docBase. Then
JkMount /*.jsp worker-name
JkMount /something-typically-servlet/* ajp13
John
So it's gonna be something like:

The Apache Vhost:
<VirtualHost xxx.xxx.xxx.xxx>
JKMount /*.jsp tomcat1
JKMount /fooservlet tomcat1
DocumentRoot /home/webhome/atm/htdocs/
ServerName www.foo.com
ServerAlias foo.com
ErrorLog /var/log/atm/error_log
CustomLog /var/log/atm/access_log combined
</VirtualHost>

relates to the TC Host:
<Host name="www.foo.com" debug="0" appBase="webapps" unpackWARs="true">
<Alias>foo.com</Alias>
<Context path="" docBase="home/webhome/atm" debug="0"
reloadable="true"/>
</Host>


AND
<VirtualHost xxx.xxx.xxx.xxx>
JKMount /*.jsp tomcat1
JKMount /fooservlet tomcat1
DocumentRoot /home/webhome/bdg/htdocs/
ServerName www.foo2.com
ServerAlias foo2.com
ErrorLog /var/log/bdg/error_log
CustomLog /var/log/bdg/access_log combined
</VirtualHost>

relates to the TC Host:
<Host name="www.foo2.com" debug="0" appBase="webapps" unpackWARs="true">
<Alias>foo2.com</Alias>
<Context path="" docBase="home/webhome/bdg" debug="0"
reloadable="true"/>
</Host>



Is that correct? In this case, I'm replacing /ATM and /BDG apps with to
Hosts under TC, with the default Context set to be a separate instance
of that 'common' app.

I'm wondering about this from workers.properties:

worker.list=tomcat1
worker.tomcat1.host=localhost

Will I need to define a new work for each new host in TC,or can I supply
a comma separated list to the worker.tomcat1.host entry?


As for the 'illegal' and 'scary' mappings we have.. I'm sure we just
picked them up from googling and well, you know how valid some of the
info out there is. We've also got some attributes on Contexts that I
can't find docos for. They don't seem to hurt though. After I've ironed
out these issues, I'm doing a 'clean sweep' of all the files (after
backup of course) and 'HOWTO' for myself and colleagues at work.

Thanks very much John. :)
John Turner
2003-09-03 21:37:17 UTC
Permalink
Post by Mike Curwen
<VirtualHost xxx.xxx.xxx.xxx>
JKMount /*.jsp tomcat1
JKMount /fooservlet tomcat1
DocumentRoot /home/webhome/atm/htdocs/
ServerName www.foo.com
ServerAlias foo.com
ErrorLog /var/log/atm/error_log
CustomLog /var/log/atm/access_log combined
</VirtualHost>
<Host name="www.foo.com" debug="0" appBase="webapps" unpackWARs="true">
<Alias>foo.com</Alias>
<Context path="" docBase="home/webhome/atm" debug="0"
reloadable="true"/>
</Host>
Yeah, but I typically make DocumentRoot = ROOT docBase. So on my
servers I have something like this:

<Host name="www.VIRTHOST.com" debug="1" appBase="VIRTHOST"
unpackWARs="true" autoDeploy="true">
<Context path="" docBase="VIRTHOST" debug="0" reloadable="true">
</Context>
</Host>

and

<VirtualHost *>
ServerName www.VIRTHOST.aas.com
DocumentRoot /usr/local/jakarta-tomcat-4.1.27/VIRTHOST/VIRTHOST

# Static files
Alias / "/usr/local/jakarta-tomcat-4.1.27/VIRTHOST/VIRTHOST"

<Directory "/usr/local/jakarta-tomcat-4.1.27/VIRTHOST/VIRTHOST">
Options Indexes FollowSymLinks
DirectoryIndex index.jsp
</Directory>

# Deny direct access to WEB-INF and META-INF
<Location "/WEB-INF/*">
AllowOverride None
deny from all
</Location>
<Location "/META-INF/*">
AllowOverride None
deny from all
</Location>

JkMount /* ajp13
</VirtualHost>

Which makes the following dir structure possible:

appBase
$CATALINA_HOME/VIRTHOST

Apache DocumentRoot, and TC root Context, path="", docBase="VIRTHOST":
$CATALINA_HOME/VIRTHOST/VIRTHOST

other Context, path="/SOME_OTHER_APP", docBase="SOME_OTHER_APP":
$CATALINA_HOME/VIRTHOST/SOME_OTHER_APP

Yes, #2 above is redundant with having the same dir name twice, but it
makes sense to me. You could just as easily change it to ROOT or
something else, but in my case, with many virtual hosts, I found myself
saying "ok, this is ROOT, but WHICH ROOT?". Using the domain name as
the actual name of the directory for the root web app gets rid of this
problem.

For other Contexts, you just add additional Alias commands to httpd.conf
to get Apache to recognize dirs on the same level as the DocRoot instead
of sub-dirs.
Post by Mike Curwen
Is that correct? In this case, I'm replacing /ATM and /BDG apps with to
Hosts under TC, with the default Context set to be a separate instance
of that 'common' app.
Pretty much, I would just watch the DocumentRoot and Alias in
httpd.conf, they can play tricks on you if you have them pointing to
directories one level above or below your Context's docBase.
Post by Mike Curwen
worker.list=tomcat1
worker.tomcat1.host=localhost
Will I need to define a new work for each new host in TC,or can I supply
a comma separated list to the worker.tomcat1.host entry?
No, you only need one worker. ".host" = "location of machine running
Tomcat", it does not need to match any virtual host name. I used to
think it did, back in the day, but I have since seen the error of my
ways and have come back to the straight and narrow. A basic 4-line
workers.properties will work for many virtual hosts. I have servers
with 5, 8, and 22 virtual hosts, all using one worker per physical
server with no problems.
Post by Mike Curwen
Thanks very much John. :)
Glad to help, if I am. Have fun.

John
Ralph Einfeldt
2003-09-04 05:59:55 UTC
Permalink
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.
Post by Richard Hill
-----Original Message-----
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-----
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.
John Bell
2003-09-04 07:35:52 UTC
Permalink
The recently installed Tomcat 4.1.24 on startup takes about 60M of memory.
Is it my configuration. I have not noticed previous versions consuming so
much.
I have 6 or so applications in webapps - mainly struts - documentaion,
examples etc.
Using j2sdk1.4.0.

Regards
Hertenstein Alain
2003-09-04 07:42:29 UTC
Permalink
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:***@msci.ca]
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" <***@sgi.com>
To: "tomcat" <tomcat-***@jakarta.apache.org>
Sent: Wednesday, September 03, 2003 12:56 PM
Subject: Memory leaks?
Post by Jim Lynch
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
javax.servlet.ServletException: Servlet execution threw an exception
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:269)
Post by Jim Lynch
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
Post by Jim Lynch
(Big snip)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:392)
Post by Jim Lynch
at
565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:619)
Post by Jim Lynch
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: tomcat-user-***@jakarta.apache.org
For additional commands, e-mail: tomcat-user-***@jakarta.apache.org


**********************************************************************
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.
**********************************************************************
Shapira, Yoav
2003-09-04 12:52:41 UTC
Permalink
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
Post by Richard Hill
-----Original Message-----
Sent: Thursday, September 04, 2003 2:00 AM
To: Tomcat Users List
Subject: RE: Memory leaks?
- -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.
Post by Richard Hill
-----Original Message-----
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-----
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.
---------------------------------------------------------------------
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.
Shapira, Yoav
2003-09-04 14:10:45 UTC
Permalink
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
Post by Richard Hill
-----Original Message-----
Sent: Thursday, September 04, 2003 10:05 AM
Subject: Re: Memory leaks?
Post by Jim Lynch
OK, that's probably what's going on. I know I should close
Statements
Post by Richard Hill
Post by Jim Lynch
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.
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#close()
Post by Richard Hill
(Closing a Statement also closes any open ResultSets associated with
that Statement.)
Greg
---------------------------------------------------------------------
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.
Jim Lynch
2003-09-05 14:36:33 UTC
Permalink
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.
Post by Shapira, Yoav
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
Post by Richard Hill
-----Original Message-----
Sent: Thursday, September 04, 2003 10:05 AM
Subject: Re: Memory leaks?
Post by Jim Lynch
OK, that's probably what's going on. I know I should close
Statements
Post by Richard Hill
Post by Jim Lynch
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.
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html#close()
Post by Richard Hill
(Closing a Statement also closes any open ResultSets associated with
that Statement.)
Greg
---------------------------------------------------------------------
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.
---------------------------------------------------------------------
Mike Curwen
2003-09-05 17:09:52 UTC
Permalink
Post by Jim Lynch
I seemed to have read that java/tomcat isn't
supposed to have memory leaks,
AND
Post by Jim Lynch
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?
Post by Jim Lynch
-----Original Message-----
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.
Post by Shapira, Yoav
Howdy,
You don't have to close a result set if you're closing the
statement
Post by Shapira, Yoav
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
Post by Shapira, Yoav
performance.
Yoav Shapira
Millennium ChemInformatics
Post by Richard Hill
-----Original Message-----
Sent: Thursday, September 04, 2003 10:05 AM
Subject: Re: Memory leaks?
Post by Jim Lynch
OK, that's probably what's going on. I know I should close
Statements
Post by Richard Hill
Post by Jim Lynch
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.
http://java.sun.com/j2se/1.4.2/docs/api/java/s>
ql/Statement.html#close(
Post by Jim Lynch
Post by Shapira, Yoav
)
Post by Richard Hill
(Closing a Statement also closes any open ResultSets
associated with
Post by Shapira, Yoav
Post by Richard Hill
that Statement.)
Greg
---------------------------------------------------------------------
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
Post by Shapira, Yoav
individual(s) to whom it is addressed, and may not be
saved, copied,
Post by Shapira, Yoav
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.
---------------------------------------------------------------------
---------------------------------------------------------------------
Jim Lynch
2003-09-05 17:32:09 UTC
Permalink
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.
Post by Mike Curwen
Post by Jim Lynch
I seemed to have read that java/tomcat isn't
supposed to have memory leaks,
AND
Post by Jim Lynch
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?
Post by Jim Lynch
-----Original Message-----
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.
Post by Shapira, Yoav
Howdy,
You don't have to close a result set if you're closing the
statement
Post by Shapira, Yoav
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
Post by Shapira, Yoav
performance.
Yoav Shapira
Millennium ChemInformatics
Post by Richard Hill
-----Original Message-----
Sent: Thursday, September 04, 2003 10:05 AM
Subject: Re: Memory leaks?
Post by Jim Lynch
OK, that's probably what's going on. I know I should close
Statements
Post by Richard Hill
Post by Jim Lynch
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.
http://java.sun.com/j2se/1.4.2/docs/api/java/s>
ql/Statement.html#close(
Post by Jim Lynch
Post by Shapira, Yoav
)
Post by Richard Hill
(Closing a Statement also closes any open ResultSets
associated with
Post by Shapira, Yoav
Post by Richard Hill
that Statement.)
Greg
---------------------------------------------------------------------
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
Post by Shapira, Yoav
individual(s) to whom it is addressed, and may not be
saved, copied,
Post by Shapira, Yoav
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.
---------------------------------------------------------------------
---------------------------------------------------------------------
Sai Sivanesan
2003-09-07 01:11:43 UTC
Permalink
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.
Post by Mike Curwen
Post by Jim Lynch
I seemed to have read that java/tomcat isn't
supposed to have memory leaks,
AND
Post by Jim Lynch
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?
Post by Jim Lynch
-----Original Message-----
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.
Post by Shapira, Yoav
Howdy,
You don't have to close a result set if you're closing the
statement
Post by Shapira, Yoav
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
Post by Shapira, Yoav
performance.
Yoav Shapira
Millennium ChemInformatics
Post by Richard Hill
-----Original Message-----
Sent: Thursday, September 04, 2003 10:05 AM
Subject: Re: Memory leaks?
Post by Jim Lynch
OK, that's probably what's going on. I know I should close
Statements
Post by Richard Hill
Post by Jim Lynch
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.
http://java.sun.com/j2se/1.4.2/docs/api/java/s>
ql/Statement.html#close(
Post by Jim Lynch
Post by Shapira, Yoav
)
Post by Richard Hill
(Closing a Statement also closes any open ResultSets
associated with
Post by Shapira, Yoav
Post by Richard Hill
that Statement.)
Greg
---------------------------------------------------------------------
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
Post by Shapira, Yoav
individual(s) to whom it is addressed, and may not be
saved, copied,
Post by Shapira, Yoav
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.
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
--
Open WebMail Project (http://openwebmail.org)

Hookom, Jacob
2003-09-04 14:12:55 UTC
Permalink
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:gward-***@python.net]
Sent: Thursday, September 04, 2003 9:05 AM
To: Tomcat Users List; ***@sgi.com
Subject: Re: Memory leaks?
Post by Jim Lynch
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: tomcat-user-***@jakarta.apache.org
For additional commands, e-mail: tomcat-user-***@jakarta.apache.org
Nikola Milutinovic
2003-09-05 05:44:14 UTC
Permalink
Post by Hookom, Jacob
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 sh
Tim Funk
2003-09-05 11:01:59 UTC
Permalink
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
Post by Nikola Milutinovic
Post by Hookom, Jacob
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.
John Turner
2003-09-05 12:36:32 UTC
Permalink
Post by Tim Funk
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
Tim Funk
2003-09-05 12:46:11 UTC
Permalink
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
Post by John Turner
Post by Tim Funk
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
Christopher Williams
2003-09-05 14:26:56 UTC
Permalink
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.
Continue reading on narkive:
Loading...