Re: [OT] Serious memory leak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Balazs,
Balazs Michnay wrote:
> Somewhere I read that the GC can only collect objects that were
> instantiated with the "new" keyword.
That's an odd way of putting it. The garbage collector only works with
the heap. Since in Java nearly everything is on the heap (or, rather, it
appears that everything is on the heap, which is all you really need to
know), the garbage collector basically cleans up everything.
> Does it mean the the following two String creations differ when it
> comes to garbage collection?
>
> 1) String myString = "This is my string";
> 2) String myString = new String("This is my string");
>
> If the second one can only be garbage collected, this would explain
> my uncollectable char[] objects, because mostly I simply use the 1)
> version.
>
> If you say this really does count when it comes to garbage
> collection, I'd rewrite my code and see what happens.
Well, you're introduced an odd concept into the discussion: the Java
class file constant pool. When you compile a string into a class file
(in this case, "This is my string"), the compiler puts the UTF-8
representation of it into a part of the class file itself. When line 1
of your code executes, no constructor is called... the java bytecode
primitive "ldc" (load constant) is called which returns the String
object directly.
In the case of line #2, a new String object is allocated, the constant
is loaded, and then the constructor String.(String) is called.
You can see this yourself by compiling this simple class and then
decompiling it:
$ cat StringTest.java
public class StringTest
{
public void s1()
{
String s1 = "This is a String";
}
public void s2()
{
String s2 = new String("This is a String");
}
}
$ javac StringTest.java
$ javap -c StringTest
Compiled from "StringTest.java"
public class StringTest extends java.lang.Object{
public StringTest();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."":()V
4: return
public void s1();
Code:
0: ldc #2; //String This is a String
2: astore_1
3: return
public void s2();
Code:
0: new #3; //class java/lang/String
3: dup
4: ldc #2; //String This is a String
6: invokespecial #4; //Method
java/lang/String."":(Ljava/lang/String;)V
9: astore_1
10: return
}
In the examples you have given, I'm not entirely sure what the role of
the GC is when it comes to constants loaded from the constant pool. The
class file format contains only the UTF-8 representation of the String,
so at some point a String object /must/ be constructed in memory. You'd
have to do some more research into the JVM specification to see how
constant Strings are handled.
You probably shouldn't have lots of string constants that contain a
/lot/ of text. Maybe 400 characters or so ought to be fine (say, a
semi-complex SQL query), but if you are talking about tons of text, you
might want to read that kind of thing out of a file.
Hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGf73U9CaO5/Lv0PARAvsGAJ97ZDUpN4bhtfjE1w+/sm8tNxYp6gCgtxGt
CCIkTDuPsGGgMFmYfnh5nz0=
=DdN4
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Serious memory leak
I was wondering about one more thing...
Somewhere I read that the GC can only collect objects that were instantiated
with the "new" keyword.
Does it mean the the following two String creations differ when it comes to
garbage collection?
1) String myString = "This is my string";
2) String myString = new String("This is my string");
If
the second one can only be garbage collected, this would explain my
uncollectable char[] objects, because mostly I simply use the 1)
version.
If you say this really does count when it comes to garbage collection, I'd
rewrite my code and see what happens.
Thanks a lot,
MB.
- Original Message
From: Christopher Schultz <[EMAIL PROTECTED]>
To: Struts Users Mailing List
Sent: Wednesday, June 20, 2007 2:29:29 PM
Subject: Re: [OT] Serious memory leak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Balazs,
Balazs Michnay wrote:
> Thanks a lot, these changes really did help, now MySQL reports that
> only one connection is used all over the website. I really do
> appreciate your help.
No problem. Another good tip is to set your connection pool size to 1
when working in development (and maybe even test). This will allow your
connection pool to be exhausted any time there is a potential for
deadlock (from the cp, that is).
Good luck,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGeR2o9CaO5/Lv0PARAspgAJ4yMYS06yOQ5CLE29ezyf1D5oaLhQCfWXuu
GHdfh1DPw+q/1WXEByma8L4=
=8bHg
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Ready
for the edge of your seat?
Check out tonight's top picks on Yahoo! TV.
http://tv.yahoo.com/
Re: [OT] Serious memory leak
I was wondering about one more thing...
Somewhere I read that the GC can only collect objects that were instantiated
with the "new" keyword.
Does it mean the the following two String creations differ when it comes to
garbage collection?
1) String myString = "This is my string";
2) String myString = new String("This is my string");
If the second one can only be garbage collected, this would explain my
uncollectable char[] objects, because mostly I simply use the 1) version.
If you say this really does count when it comes to garbage collection, I'd
rewrite my code and see what happens.
Thanks a lot,
MB.
- Original Message
From: Christopher Schultz <[EMAIL PROTECTED]>
To: Struts Users Mailing List
Sent: Wednesday, June 20, 2007 2:29:29 PM
Subject: Re: [OT] Serious memory leak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Balazs,
Balazs Michnay wrote:
> Thanks a lot, these changes really did help, now MySQL reports that
> only one connection is used all over the website. I really do
> appreciate your help.
No problem. Another good tip is to set your connection pool size to 1
when working in development (and maybe even test). This will allow your
connection pool to be exhausted any time there is a potential for
deadlock (from the cp, that is).
Good luck,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGeR2o9CaO5/Lv0PARAspgAJ4yMYS06yOQ5CLE29ezyf1D5oaLhQCfWXuu
GHdfh1DPw+q/1WXEByma8L4=
=8bHg
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
Re: [OT] Serious memory leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Balazs, Balazs Michnay wrote: > Thanks a lot, these changes really did help, now MySQL reports that > only one connection is used all over the website. I really do > appreciate your help. No problem. Another good tip is to set your connection pool size to 1 when working in development (and maybe even test). This will allow your connection pool to be exhausted any time there is a potential for deadlock (from the cp, that is). Good luck, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeR2o9CaO5/Lv0PARAspgAJ4yMYS06yOQ5CLE29ezyf1D5oaLhQCfWXuu GHdfh1DPw+q/1WXEByma8L4= =8bHg -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Serious memory leak
Chris,
Thanks a lot, these changes really did help, now MySQL reports that only one
connection is used all over the website.
I really do appreciate your help.
Regards,
MB
- Original Message
From: Christopher Schultz <[EMAIL PROTECTED]>
To: Struts Users Mailing List
Sent: Tuesday, June 19, 2007 7:10:49 PM
Subject: Re: [OT] Serious memory leak
Balazs,
Balazs Michnay wrote:
> recently I found
> out that my memory consumption of my
> application is nothing compared to the memory consumption of my database
> server (MySQL).
>
> I'm theoretically using connection pool to save resources of my
> database server, but each time I make a query, I have a brand new
> connection.
Well... are you /theoretically/ or /actually/ using a JDBC connection pool?
> Why doesn't PID 11 use the connection used by PID 10?
> There might be
> some errors in my code, however, it was previously
> reviewed and said to be correct.
Do you trust the reviewer? Looking at the code you posted, I would not
trust them any more :(
> private Statement getConnectionStatement(Connection conn) throws Exception {
>
> Context ctx = new InitialContext();
> if(ctx == null )
> throw new Exception("Boom - No Context");
>
> Context envCtx = (Context) ctx.lookup("java:comp/env");
> DataSource ds = (DataSource) envCtx.lookup("jdbc/akr_db");
>
> if (ds != null) {
>
> conn = ds.getConnection();
> if(conn == null) throw new Exception();
>
> } else throw new Exception();
>
> return conn.createStatement();
> }
Do you pass an active connection to this method? If you do, then you are
leaking connections every time you try to create a statement. If you are
always passing "null", then why do you have the Connection parameter to
this method?
A proper method with the above signature should be implemented like this:
private Statement getConnectionStatement(Connection conn)
{
return conn.createStatement();
}
As you can see, this method is completely worthless. It looks like your
method ought to be this instead:
private Connection getConnection()
{
Context ctx = new InitialContext();
if(ctx == null )
throw new Exception("Boom - No Context");
Context envCtx = (Context) ctx.lookup("java:comp/env");
// Consider checking envCtx against null, here, too
// Consider making the JNDI resource name configurable
// instead of hard-coding.
DataSource ds = (DataSource) envCtx.lookup("jdbc/akr_db");
if (ds != null) {
conn = ds.getConnection();
if(conn == null) throw new Exception();
} else throw new Exception();
return conn;
}
The closeConnection method looks fine except for these style comments:
1. Call this method "close"... it closes much more than the connection.
2. Don't swallow the SQLExceptions. At least log them, but never
swallow an exception!
3. Don't bother setting each reference to null. This is a waste of time,
and clutters the code.
Selected lines from your code:
> Connection conn = null;
> try {
> stmt = getConnectionStatement(conn);
// Note that conn is still null here.
> } catch (Exception e) {
> System.err.println(e.getMessage());
> } finally {
> closeConnection(conn,stmt,rst);
> }
Conn is still null, so it will never be closed.
YOU ARE LEAKING CONNECTIONS. FIX YOUR CODE.
It should look like this:
Connection conn = null;
Statement stmt = null; // Or PreparedStatement if needed
ResultSet rst = null;
String query = "SELECT * FROM MyTable";
try {
conn = getConnection();
stmt = conn.createStatement();
rst = stmt.executeQuery(query);
// YOU SHOULD CHECK THIS FOR false:
rst.next();
this.setTartam(rst.getString("tartam"));
} catch (Exception e) {
System.err.println(e.getMessage());
} finally {
closeConnection(conn,stmt,rst);
}
Note that PreparedStatements are universally better than bare Statements
when using parameterized queries (which you are not using, here).
These changes should help A LOT. You are probably leaking connections
all over the place. I'm curious as to why you aren't getting messages on
stderr that your connection pool is empty...
-chris
Building a website is a piece of cake. Yahoo! Small Business gives you all the
tools to get online.
http://smallbusiness.yahoo.com/webhosting
Re: [OT] Serious memory leak
Balazs,
Balazs Michnay wrote:
> recently I found
> out that my memory consumption of my
> application is nothing compared to the memory consumption of my database
> server (MySQL).
>
> I'm theoretically using connection pool to save resources of my
> database server, but each time I make a query, I have a brand new
> connection.
Well... are you /theoretically/ or /actually/ using a JDBC connection pool?
> Why doesn't PID 11 use the connection used by PID 10?
> There might be
> some errors in my code, however, it was previously
> reviewed and said to be correct.
Do you trust the reviewer? Looking at the code you posted, I would not
trust them any more :(
> private Statement getConnectionStatement(Connection conn) throws Exception {
>
> Context ctx = new InitialContext();
> if(ctx == null )
> throw new Exception("Boom - No Context");
>
> Context envCtx = (Context) ctx.lookup("java:comp/env");
> DataSource ds = (DataSource) envCtx.lookup("jdbc/akr_db");
>
> if (ds != null) {
>
> conn = ds.getConnection();
> if(conn == null) throw new Exception();
>
> } else throw new Exception();
>
> return conn.createStatement();
> }
Do you pass an active connection to this method? If you do, then you are
leaking connections every time you try to create a statement. If you are
always passing "null", then why do you have the Connection parameter to
this method?
A proper method with the above signature should be implemented like this:
private Statement getConnectionStatement(Connection conn)
{
return conn.createStatement();
}
As you can see, this method is completely worthless. It looks like your
method ought to be this instead:
private Connection getConnection()
{
Context ctx = new InitialContext();
if(ctx == null )
throw new Exception("Boom - No Context");
Context envCtx = (Context) ctx.lookup("java:comp/env");
// Consider checking envCtx against null, here, too
// Consider making the JNDI resource name configurable
// instead of hard-coding.
DataSource ds = (DataSource) envCtx.lookup("jdbc/akr_db");
if (ds != null) {
conn = ds.getConnection();
if(conn == null) throw new Exception();
} else throw new Exception();
return conn;
}
The closeConnection method looks fine except for these style comments:
1. Call this method "close"... it closes much more than the connection.
2. Don't swallow the SQLExceptions. At least log them, but never
swallow an exception!
3. Don't bother setting each reference to null. This is a waste of time,
and clutters the code.
Selected lines from your code:
> Connection conn = null;
> try {
> stmt = getConnectionStatement(conn);
// Note that conn is still null here.
> } catch (Exception e) {
> System.err.println(e.getMessage());
> } finally {
> closeConnection(conn,stmt,rst);
> }
Conn is still null, so it will never be closed.
YOU ARE LEAKING CONNECTIONS. FIX YOUR CODE.
It should look like this:
Connection conn = null;
Statement stmt = null; // Or PreparedStatement if needed
ResultSet rst = null;
String query = "SELECT * FROM MyTable";
try {
conn = getConnection();
stmt = conn.createStatement();
rst = stmt.executeQuery(query);
// YOU SHOULD CHECK THIS FOR false:
rst.next();
this.setTartam(rst.getString("tartam"));
} catch (Exception e) {
System.err.println(e.getMessage());
} finally {
closeConnection(conn,stmt,rst);
}
Note that PreparedStatements are universally better than bare Statements
when using parameterized queries (which you are not using, here).
These changes should help A LOT. You are probably leaking connections
all over the place. I'm curious as to why you aren't getting messages on
stderr that your connection pool is empty...
-chris
signature.asc
Description: OpenPGP digital signature
Re: [OT] Serious memory leak
I forgot to include the link to the image. Here it is:
http://www.inf.u-szeged.hu/~michnay/db/db_connections.jpg
- Original Message
From: Balazs Michnay <[EMAIL PROTECTED]>
To: Struts Users Mailing List
Sent: Tuesday, June 19, 2007 2:16:06 PM
Subject: Re: [OT] Serious memory leak
Thanks for your reply on the memory leak issue
Well, recently I found out that my memory consumption of my application is
nothing compared to the memory consumption of my database server (MySQL).
I'm theoretically using connection pool to save resources of my database
server, but each time I make a query, I have a brand new connection.
Please take a look at the following image that shows the state of my user
connection.
I have lots of connections, however theses are only different queries from the
same web application.
Why doesn't PID 11 use the connection used by PID 10?
There might be some errors in my code, however, it was previously reviewed and
said to be correct.
Please take a look at the following source...
I have 2 methods related to my connection pool:
---GETTING CONNECTION
---
private Statement getConnectionStatement(Connection conn) throws Exception {
Context ctx = new InitialContext();
if(ctx == null )
throw new Exception("Boom - No Context");
Context envCtx = (Context) ctx.lookup("java:comp/env");
DataSource ds = (DataSource) envCtx.lookup("jdbc/akr_db");
if (ds != null) {
conn = ds.getConnection();
if(conn == null) throw new Exception();
} else throw new Exception();
return conn.createStatement();
}
-
---CLOSING CONNECTION
---
private void closeConnection(Connection conn, Statement stmt, ResultSet rst) {
// Always make sure result sets and statements are closed,
// and the connection is returned to the pool
if (stmt != null) {
try { stmt.close(); } catch (SQLException e) { ; }
stmt = null;
}
if (conn != null) {
try { conn.close(); } catch (SQLException e) { ; }
conn = null;
}
if (rst != null) {
try { rst.close(); } catch (SQLException e) { ; }
rst = null;
}
}
-
---USING CONNECTION POOL IN A
METHOD-
Connection conn = null;
Statement stmt = null; // Or PreparedStatement if needed
ResultSet rst = null;
String query = "SELECT * FROM MyTable";
try {
stmt = getConnectionStatement(conn);
rst = stmt.executeQuery(query);
rst.next();
this.setTartam(rst.getString("tartam"));
} catch (Exception e) {
System.err.println(e.getMessage());
} finally {
closeConnection(conn,stmt,rst);
}
-
Furthermore, I have a context.xml with the following content:
-
In the web.xml I have an entry related to my db connection:
DB Connection Pooling
jdbc/akr_db
javax.sql.DataSource
Container
--
--
That's all I have related to database connection.
What am I doing wrong?
Thanks a lot,
MB
- Original Message
From: Christopher Schultz <[EMAIL PROTECTED]>
To: Struts Users Mailing List
Sent: Wednesday, May 30, 2007 5:45:11 PM
Subject: Re: [OT] Serious memory leak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Balazs,
I just realized that we're talking about approximately 1MB of char[]
data... what's the big deal about that? ;)
Balazs Michnay wrote:
>> Can you expand the "+" next to Arrays.copyOfRange to see what the rest
>> of the stack trace is? I'm sure that a lot of things call
>> Arrays.copyOfRange, so it's hard to determine what the problem is. Post
>> another
Re: [OT] Serious memory leak
Thanks for your reply on the memory leak issue
Well, recently I found out that my memory consumption of my application is
nothing compared to the memory consumption of my database server (MySQL).
I'm theoretically using connection pool to save resources of my database
server, but each time I make a query, I have a brand new connection.
Please take a look at the following image that shows the state of my user
connection.
I have lots of connections, however theses are only different queries from the
same web application.
Why doesn't PID 11 use the connection used by PID 10?
There might be some errors in my code, however, it was previously reviewed and
said to be correct.
Please take a look at the following source...
I have 2 methods related to my connection pool:
---GETTING CONNECTION
---
private Statement getConnectionStatement(Connection conn) throws Exception {
Context ctx = new InitialContext();
if(ctx == null )
throw new Exception("Boom - No Context");
Context envCtx = (Context) ctx.lookup("java:comp/env");
DataSource ds = (DataSource) envCtx.lookup("jdbc/akr_db");
if (ds != null) {
conn = ds.getConnection();
if(conn == null) throw new Exception();
} else throw new Exception();
return conn.createStatement();
}
-
---CLOSING CONNECTION
---
private void closeConnection(Connection conn, Statement stmt, ResultSet rst) {
// Always make sure result sets and statements are closed,
// and the connection is returned to the pool
if (stmt != null) {
try { stmt.close(); } catch (SQLException e) { ; }
stmt = null;
}
if (conn != null) {
try { conn.close(); } catch (SQLException e) { ; }
conn = null;
}
if (rst != null) {
try { rst.close(); } catch (SQLException e) { ; }
rst = null;
}
}
-
---USING CONNECTION POOL IN A
METHOD-
Connection conn = null;
Statement stmt = null; // Or PreparedStatement if needed
ResultSet rst = null;
String query = "SELECT * FROM MyTable";
try {
stmt = getConnectionStatement(conn);
rst = stmt.executeQuery(query);
rst.next();
this.setTartam(rst.getString("tartam"));
} catch (Exception e) {
System.err.println(e.getMessage());
} finally {
closeConnection(conn,stmt,rst);
}
-
Furthermore, I have a context.xml with the following content:
-
In the web.xml I have an entry related to my db connection:
DB Connection Pooling
jdbc/akr_db
javax.sql.DataSource
Container
--
--
That's all I have related to database connection.
What am I doing wrong?
Thanks a lot,
MB
- Original Message
From: Christopher Schultz <[EMAIL PROTECTED]>
To: Struts Users Mailing List
Sent: Wednesday, May 30, 2007 5:45:11 PM
Subject: Re: [OT] Serious memory leak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Balazs,
I just realized that we're talking about approximately 1MB of char[]
data... what's the big deal about that? ;)
Balazs Michnay wrote:
>> Can you expand the "+" next to Arrays.copyOfRange to see what the rest
>> of the stack trace is? I'm sure that a lot of things call
>> Arrays.copyOfRange, so it's hard to determine what the problem is. Post
>> another screenshot if you can.
>
> Sure,
> here it is (profiler3_expanded.JPG):
> http://www.inf.u-szeged.hu/~michnay/profiler/
> As you can see, now there are other methods as well allocating char[] objects.
> It's pretty confusing and very hard to track how exactly my pages are
Re: [OT] Serious memory leak
Maybe you're creating a new session with each request. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Serious memory leak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Balazs,
I just realized that we're talking about approximately 1MB of char[]
data... what's the big deal about that? ;)
Balazs Michnay wrote:
>> Can you expand the "+" next to Arrays.copyOfRange to see what the rest
>> of the stack trace is? I'm sure that a lot of things call
>> Arrays.copyOfRange, so it's hard to determine what the problem is. Post
>> another screenshot if you can.
>
> Sure,
> here it is (profiler3_expanded.JPG):
> http://www.inf.u-szeged.hu/~michnay/profiler/
> As you can see, now there are other methods as well allocating char[] objects.
> It's pretty confusing and very hard to track how exactly my pages are
> processed by the server... at least, it is for me... :)
It looks like most of those char[] objects are being allocated by Sun's
HTTP client. What are you loading over HTTP? Class files? Apparently,
you have some big arrays lying around:
2 * 16k bytes allocated by HttpClient.parseHTTP
39 * 16k bytes allocated by HttpClient. (the constructor)
These look like buffers. I'd be interested in seeing what is using
HttpClient in your code (or Struts, I suppose).
The other section (copyOfRange) has created lots of String objects. Some
of them are obvious: you are reading properties from properties files
and they take up memory. StringBuilder is often used by the compiler to
assemble Strings combined using the + operator (for Strings). You can
use it yourself, too, just like a StringBuffer. Somewhere, strings are
being created (which, of course, are made-up almost entirely of char[]
objects).
> I'll
> try to factor out the JNDI parts. Should I factor out the creation of
> statement and result objects as well, or only the connection should be
> factored out?
I would only do the Connection. What else would you do? Have a method
like this?
public Statement createStatement(Connection conn, String sql)
{
return conn.createStatement(sql);
}
??! That's a pretty worthless method.
> Should I create another method to free up the resources?
I have done that myself:
protected void close(Connection conn, Statement s, ResultSet r)
{
/// this guy is protected because it's in a superclass
// for each object, check for null, try { close } catch { log }
}
>> In terms of design, I would write that method to return a List of
>> application-specific objects instead of maintaining two separate
>> (untyped) lists that just happen to be related. It is a much more
>> understandable design and yields much more readable code. It will also
>> simplify your JSP loop, etc.
>
> What do you mean by "List of application-specific objects"? Is it a
> multi-dimensional ArrayList object? I'm very interested in creating
> well-readable and well-understandable code, so some samples would be
> appreciated :) (sorry, I'm not very experienced in Java)
I know how you feel. We used to have a programmer who didn't realize he
could create his own types. Stop thinking that everything has to be a
String hidden inside a baffling maze of nested Lists and Maps. If you
have an entity that you like to think of as a "person" (for example),
then you can represent this data in at least two ways:
1. Use a List of Strings where the index of the string has meaning,
but only in your head. Something like this:
ArrayList person = new ArrayList();
person.add("Chris"); // 0 == first name
person.add("Schultz"); // 1 == last name
person.add("Male");// 2 == gender
ArrayList people = new ArrayList();
people.add(person);
// etc.
2. Use an object you define yourself.
public class Person
{
String firstName;
String lastName;
}
ArrayList people = new ArrayList();
people.add(new Person("Chris", "Schultz", "Male"));
// etc.
If you use solution #1, you'll never know if the ArrayList you're
getting is an array of String representing "person" entities or a list
of strings representing "Account" entities, or whatever. You basically
have to cross your fingers and hope that the documentation for the
method is correct.
If you use #2, you can use the compiler and runtime to enforce your
notion of what is what: That list /does/ contain Person objects. You
seriously simplify your code and rarely get confused. You save a lot of
memory, too, since ArrayLists have overhead that you don't need if you
use your own objects.
These things are typically called "business objects", but only when they
map into domain-specific entities (meaning that they represent real
concepts in the language of the problem... like "Account" for financial
software, or "PurchaseOrder" for an ordering system).
You are free to create other types that are useful to you even if they
are not "business objects" per se any time you find yourself
stuffing things like bare Strings into Maps or Lists, ask yourself if
you shouldn't be defining your own type (or class... or object... or
whatever you want to call it).
>> Do you see any place where objects could not be fr
Re: Serious memory leak
>I meant filters defined in web.xml, not scriptlets. It's /possible/ that >your tags are using a whole lot of memory, but probably not >(you'd have to be creating randomly-named session attributes over and >over, and never freeing them... I'm guessing you're not doing that). No, I'm not doing that. They are only tags displaying some text... There are no filters or any special contents in my web.xml. >Can you expand the "+" next to Arrays.copyOfRange to see what the rest >of the stack trace is? I'm sure that a lot of things call >Arrays.copyOfRange, so it's hard to determine what the problem is. Post >another screenshot if you can. Sure, here it is (profiler3_expanded.JPG): http://www.inf.u-szeged.hu/~michnay/profiler/ As you can see, now there are other methods as well allocating char[] objects. It's pretty confusing and very hard to track how exactly my pages are processed by the server... at least, it is for me... :) >Your code looks just fine, although I might suggest factoring-out the >code to mess with JNDI, the DataSource, etc. and just write a method >that returns a Connection (or throws an exception). You are also closing >your resources out of order (stmt first, then conn, then rst). Since >you're closing those resources in your finally block, why bother closing >them in the method body? It will be a cleaner method without this extra >stuff in there, but functionally equivalent. I'll try to factor out the JNDI parts. Should I factor out the creation of statement and result objects as well, or only the connection should be factored out? Should I create another method to free up the resources? I'm not sure what's the best way of doing this. Do you have a sample code to take a look at? >In terms of design, I would write that method to return a List of >application-specific objects instead of maintaining two separate >(untyped) lists that just happen to be related. It is a much more >understandable design and yields much more readable code. It will also >simplify your JSP loop, etc. What do you mean by "List of application-specific objects"? Is it a multi-dimensional ArrayList object? I'm very interested in creating well-readable and well-understandable code, so some samples would be appreciated :) (sorry, I'm not very experienced in Java) >Do you see any place where objects could not be freed-up? Where? I'll show you. Please take a look at profiler4.JPG found at the same URL. The big black curly bracket shows how the memory is eaten up by simle page reloads. The profiler's GC button can be found at the upper-left corner indicated by the green arrow. By pressing GC, a small amount of memory is freed up, which can be seen in the yellow ellipse. It's a little slope indicating that a very little amount of memory could be freed up, no matter how many times I press the GC button. What about the rest? That's pretty confusing and sometimes a bit annoying, because I don't see where my code wastes ~25 Mbytes of memory... >Ouch! If you reload many times, does a JVM-initiated GC fire off? You >should be able to look at the GC graph to see if the JVM is at least >attempting to to a GC. It's possible to limit your JVM so much that even >simple things cause OOMs, especially /during/ GC runs. No, it's me firing off a GC by pressing the GC button of the profiler. There are no GC calls in my code... >You mentioned you were using Tomcat as well. I'm assuming that since >you're using Java 1.6 (Sun?), you're also using Tomcat 5.x or 6.x? Oh, yes, sorry, I'm using Tomcat 5.5 (bundled with NetBeans 5.5.17), MySQL server 5.0.37, under Win XP SP2. >No problem. We'll figure it out... but it might take a while. I remember >when I first started profiling my apps. I started freaking out because I >had no idea so many objects existed. At first I thought everything was >leaking memory, and it turns out that everything was working just fine. >The GC can play lots of tricks on you if you don't fully understand what >you're seeing. Yes, you're absolutely right, that's exactly what I think. I was about to accept that I'm just simply unable to comprehend what happen behind the scenes, but now - thanks to your helpfulness and willingness to help - things are getting clearer... You just simply don't see how much you help. Apart from the fact that my code is whether wastes or doesn't waste ~25 Mbytes of memory by virtually "doing nothing", it's very calming to see that other factors not directly related to my code can affect memory load. I appreciate every bits of help. Regards, BM Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/
Re: Serious memory leak
On 22/05/07, Balazs Michnay <[EMAIL PROTECTED]> wrote: Hi, I have just downloaded NetBeans Profiler to see how my web-app performs and realized that it produces serious memory leaks... The interesting part is that I have nothing on my JSP but static struts tags (no dynamic content at all) and it turned out that the leaks are not made by my application, but made by either struts (???) or Tomcat (???) or Java itself, I don't know what... I don't want to be seen to be teaching my grannie to suck eggs, but are you doing your profiling with a clean start of Netbeans and Tomcat? I've just been indulging in a fairly rapid cycle of develop, deploy in-situ, test using Netbeans and the embedded Tomcat, and have crashed with an OOM error. So something in Netbeans or, more likely, Tomcat is holding resource when you re-deploy in-situ. Regards Roger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serious memory leak
>I meant filters defined in web.xml, not scriptlets. It's /possible/ that >your tags are using a whole lot of memory, but probably not >(you'd have to be creating randomly-named session attributes over and >over, and never freeing them... I'm guessing you're not doing that). No, I'm not doing that. They are only tags displaying some text... There are no filters or any special contents in my web.xml. >Can you expand the "+" next to Arrays.copyOfRange to see what the rest >of the stack trace is? I'm sure that a lot of things call >Arrays.copyOfRange, so it's hard to determine what the problem is. Post >another screenshot if you can. Sure, here it is (profiler3_expanded.JPG): http://www.inf.u-szeged.hu/~michnay/profiler/ As you can see, now there are other methods as well allocating char[] objects. It's pretty confusing and very hard to track how exactly my pages are processed by the server... at least, it is for me... :) >Your code looks just fine, although I might suggest factoring-out the >code to mess with JNDI, the DataSource, etc. and just write a method >that returns a Connection (or throws an exception). You are also closing >your resources out of order (stmt first, then conn, then rst). Since >you're closing those resources in your finally block, why bother closing >them in the method body? It will be a cleaner method without this extra >stuff in there, but functionally equivalent. I'll try to factor out the JNDI parts. Should I factor out the creation of statement and result objects as well, or only the connection should be factored out? Should I create another method to free up the resources? I'm not sure what's the best way of doing this. Do you have a sample code to take a look at? >In terms of design, I would write that method to return a List of >application-specific objects instead of maintaining two separate >(untyped) lists that just happen to be related. It is a much more >understandable design and yields much more readable code. It will also >simplify your JSP loop, etc. What do you mean by "List of application-specific objects"? Is it a multi-dimensional ArrayList object? I'm very interested in creating well-readable and well-understandable code, so some samples would be appreciated :) (sorry, I'm not very experienced in Java) >Do you see any place where objects could not be freed-up? Where? I'll show you. Please take a look at profiler4.JPG found at the same URL. The big black curly bracket shows how the memory is eaten up by simle page reloads. The profiler's GC button can be found at the upper-left corner indicated by the green arrow. By pressing GC, a small amount of memory is freed up, which can be seen in the yellow ellipse. It's a little slope indicating that a very little amount of memory could be freed up, no matter how many times I press the GC button. What about the rest? That's pretty confusing and sometimes a bit annoying, because I don't see where my code wastes ~25 Mbytes of memory... >Ouch! If you reload many times, does a JVM-initiated GC fire off? You >should be able to look at the GC graph to see if the JVM is at least >attempting to to a GC. It's possible to limit your JVM so much that even >simple things cause OOMs, especially /during/ GC runs. No, it's me firing off a GC by pressing the GC button of the profiler. There are no GC calls in my code... >You mentioned you were using Tomcat as well. I'm assuming that since >you're using Java 1.6 (Sun?), you're also using Tomcat 5.x or 6.x? Oh, yes, sorry, I'm using Tomcat 5.5 (bundled with NetBeans 5.5.17), MySQL server 5.0.37, under Win XP SP2. >No problem. We'll figure it out... but it might take a while. I remember >when I first started profiling my apps. I started freaking out because I >had no idea so many objects existed. At first I thought everything was >leaking memory, and it turns out that everything was working just fine. >The GC can play lots of tricks on you if you don't fully understand what >you're seeing. Yes, you're absolutely right, that's exactly what I think. I was about to accept that I'm just simply unable to comprehend what happen behind the scenes, but now - thanks to your helpfulness and willingness to help - things are getting clearer... You just simply don't see how much you help. Apart from the fact that my code is whether wastes or doesn't waste ~25 Mbytes of memory by virtually "doing nothing", it's very calming to see that other factors not directly related to my code can affect memory load. I appreciate every bits of help. Regards, BM - Original Message From: Christopher Schultz <[EMAIL PROTECTED]> To: Struts Users Mailing Lis
Re: Serious memory leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Balazs, Balazs Michnay wrote: > I think it's just a "small" [GC], because sometimes when I click on > it several times, it frees up a little memory... Okay, that may be one thing complicating your instrumentation. >> Every request will eat up memory, but /should/ eventually be freed. Does >> your "simple" page have any filters operating on it? > > No. There are only struts tags and some other tags. > There are no scriptlets on it. I meant filters defined in web.xml, not scriptlets. It's /possible/ that your tags are using a whole lot of memory, but probably not (you'd have to be creating randomly-named session attributes over and over, and never freeing them... I'm guessing you're not doing that). > Well, since my last post I kept > on testing other pages and discovered that char[] and byte[] objects are > piled up by other methods as well. InflaterInputStream is there, however > it doesn't allocate as much memory than others do now. That's what I figured. From your screenshots, it appears that char[] objects are slightly worse than byte[] objects. char[] objects are almost certainly allocated for String object contents. > Now it seems that (among others) java.util.Arrays.copyOfRange eats up > lots of memory. Can you expand the "+" next to Arrays.copyOfRange to see what the rest of the stack trace is? I'm sure that a lot of things call Arrays.copyOfRange, so it's hard to determine what the problem is. Post another screenshot if you can. > This might be caused by me not properly using my > database connection pool, so here's how I use and probably everything > gets clear... I think you're speculating too much... if you were abusing your db connection pool, you'd probably be running out of connections, not memory. > 1) Every time I'd like to connect to my db, I use the java code > posted everywhere, but since I want to store more than 1 row of the > resultset, I declare an ArrayList. Probably this shouldn't be done > this way, because memory is eaten up by array operations... ArrayList doesn't store char[] anywhere, unless you are storing char[] objects in your ArrayList. Also, ArrayList uses System.arraycopy to expand and re-allocate its arrays, not Arrays.copyOfRange. > Here's my code: Your code looks just fine, although I might suggest factoring-out the code to mess with JNDI, the DataSource, etc. and just write a method that returns a Connection (or throws an exception). You are also closing your resources out of order (stmt first, then conn, then rst). Since you're closing those resources in your finally block, why bother closing them in the method body? It will be a cleaner method without this extra stuff in there, but functionally equivalent. In terms of design, I would write that method to return a List of application-specific objects instead of maintaining two separate (untyped) lists that just happen to be related. It is a much more understandable design and yields much more readable code. It will also simplify your JSP loop, etc. > It this the right way to use my connection pool? Connection pool use is just fine. Some other stuff ought to be re-thought, but it shouldn't run out of memory. > If not, this might be the reason of my memory leaks, because some > objects may not be able to be freed-up... Do you see any place where objects could not be freed-up? Where? > [InflaterInputStream allocations are] now nothing compared to those > allocated by java.util.Arrays.copyOfRange method... This is much more plausible. > Each request (a reload) causes a memory allocation of another 1-3 Mbytes that > the profiler gc() won't free up. Ouch! If you reload many times, does a JVM-initiated GC fire off? You should be able to look at the GC graph to see if the JVM is at least attempting to to a GC. It's possible to limit your JVM so much that even simple things cause OOMs, especially /during/ GC runs. >> What JVM, app server, etc. versions are you using? > > I have the latest Java installed (Version 6 Update 1). You mentioned you were using Tomcat as well. I'm assuming that since you're using Java 1.6 (Sun?), you're also using Tomcat 5.x or 6.x? > Any hey, thanks so much for taking a look at my code, and helping at all, I > appreciate it. No problem. We'll figure it out... but it might take a while. I remember when I first started profiling my apps. I started freaking out because I had no idea so many objects existed. At first I thought everything was leaking memory, and it turns out that everything was working just fine. The GC can play lots of tricks on you if you don't fully understand what you're seeing. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGVE9m9CaO5/Lv0PARAuhkAKCWqS8u2aApySB7m0lxilr4ucI71gCgnopa 0CiD7XyrXMB+3/VBnLK0/ug= =Sc62 -END PGP SIGNATURE- --
Re: Serious memory leak
Iterator ID_klinikak = login.getID_klinikak().iterator();
Iterator nev_klinikak = login.getNev_klinikak().iterator();
while ( ID_klinikak.hasNext() ) {
%>
<%=nev_klinikak.next().toString()%>
<%
}
%>
--
It this the right way to use my connection pool? If not, this might be the
reason of my memory leaks, because some objects may not be able to be
freed-up...
>When you say the profile claims that memory is eaten up in the
>InflaterInputStream constructor, I assume you mean that the memory is
>allocated in that method. It looks like the default byte buffer length
>is 512 bytes (in my Sun 1.5 source). How big are your byte arrays that
>seem to be piling up?
It's now nothing compared to those allocated by java.util.Arrays.copyOfRange
method...
Each request (a reload) causes a memory allocation of another 1-3 Mbytes that
the profiler gc() won't free up.
>I would bet that InflaterInputStream is responsible for eating up a
>chunk of memory due to class loading. Does the number of byte[] objects
>created by InflaterInputStream increase whenever you reload that page?
>Or are other objects increasing in size and/or count?
Yes, it's increased on each reload and yes, there are some increasing char[]
objects as well. (Take a look at the pictures found on the URL I posted...)
>Does your profiler confirm that all the byte[] objects are coming from
>InflaterInputStream, or does it list them separately and you browsed a
>few of them and say that they were all from that method?
No, not all, but most of them were allocated by InflaterInputStream. (Now it's
other methods causing the same thing...)
>The reason I'm asking all of these seemingly stupid questions is that,
>with many Struts users out there, and such a simple problem, either
>everyone has this problem and Struts is untenable (which is clearly not
>true), or something is unique about your environment, or you are
>misinterpreting your data.
No, I'm pretty sure that it's me not working properly, not Struts :) That's why
I posted the way I'm using my connection pool and other codes as well, so that
you can point out what I'm (not struts) doing wrong...
>What JVM, app server, etc. versions are you using?
I have the latest Java installed (Version 6 Update 1).
Any hey, thanks so much for taking a look at my code, and helping at all, I
appreciate it.
Regards,
BM
- Original Message
From: Christopher Schultz <[EMAIL PROTECTED]>
To: Struts Users Mailing List
Sent: Wednesday, May 23, 2007 2:53:44 PM
Subject: Re: Serious memory leak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Balazs,
Balazs Michnay wrote:
>> Are you sure they cannot be garbage-collected? How do you know?
>
> The profiler can perform garbage-collection at any time I press a
> button. After pressing this, no memory is freed-up :(
Are you forcing a full GC or just a small one? Depending on a /lot/ of
things, those objects might not be freed until a full GC runs.
>> Usually, JAR files are read to load class files. When class files
>> are read, their code needs to be read into memory (in byte arrays).
>> It also need to stay in memory in order to be executed. It's true,
>> class loading uses memory ;)
>
> But does it load the classes each time I reload the page?
Probably not.
> Because
> (just for testing) I have a simple, static page with only struts
> tags on it and pressing the reload button eats up some
> more memory.
Every request to the server creates many objects: request, response,
extras for any wrappers that are created going through filters, etc.
event objects fired for any session activity, maps of request parameters
(whose Strings contain lots of byte[] objects), and on and on.
Every request will eat up memory, but /should/ eventually be freed. Does
your "simple" page have any filters operating on it? How about session
interaction?
>>> After browsing through about 80-100 pages I get an OutOfMemory
>>> error...
>
>> Are you sure these facts are related? Class loading almost never
>> causes a problem unless you are loading millions of classes.
>
> Well, I'm not sure, but since my page has "nothing" on it, I don't
> know what else may cause such thing... and again, it's the profiler
> that says memory is eaten up by the constructor of
> InflaterInputStream class.
So your testing strategy looks something like this:
1. Start up app server + attach profiler
2. Wait for app server to be ready for requests
3. Request simple page
4. Go to step #3 until OOM
Is that accurate? And nobody else is using your
Re: Serious memory leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Balazs, Balazs Michnay wrote: >> Are you sure they cannot be garbage-collected? How do you know? > > The profiler can perform garbage-collection at any time I press a > button. After pressing this, no memory is freed-up :( Are you forcing a full GC or just a small one? Depending on a /lot/ of things, those objects might not be freed until a full GC runs. >> Usually, JAR files are read to load class files. When class files >> are read, their code needs to be read into memory (in byte arrays). >> It also need to stay in memory in order to be executed. It's true, >> class loading uses memory ;) > > But does it load the classes each time I reload the page? Probably not. > Because > (just for testing) I have a simple, static page with only struts > tags on it and pressing the reload button eats up some > more memory. Every request to the server creates many objects: request, response, extras for any wrappers that are created going through filters, etc. event objects fired for any session activity, maps of request parameters (whose Strings contain lots of byte[] objects), and on and on. Every request will eat up memory, but /should/ eventually be freed. Does your "simple" page have any filters operating on it? How about session interaction? >>> After browsing through about 80-100 pages I get an OutOfMemory >>> error... > >> Are you sure these facts are related? Class loading almost never >> causes a problem unless you are loading millions of classes. > > Well, I'm not sure, but since my page has "nothing" on it, I don't > know what else may cause such thing... and again, it's the profiler > that says memory is eaten up by the constructor of > InflaterInputStream class. So your testing strategy looks something like this: 1. Start up app server + attach profiler 2. Wait for app server to be ready for requests 3. Request simple page 4. Go to step #3 until OOM Is that accurate? And nobody else is using your server at the same time, right? When you say the profile claims that memory is eaten up in the InflaterInputStream constructor, I assume you mean that the memory is allocated in that method. It looks like the default byte buffer length is 512 bytes (in my Sun 1.5 source). How big are your byte arrays that seem to be piling up? I would bet that InflaterInputStream is responsible for eating up a chunk of memory due to class loading. Does the number of byte[] objects created by InflaterInputStream increase whenever you reload that page? Or are other objects increasing in size and/or count? Does your profiler confirm that all the byte[] objects are coming from InflaterInputStream, or does it list them separately and you browsed a few of them and say that they were all from that method? The reason I'm asking all of these seemingly stupid questions is that, with many Struts users out there, and such a simple problem, either everyone has this problem and Struts is untenable (which is clearly not true), or something is unique about your environment, or you are misinterpreting your data. What JVM, app server, etc. versions are you using? Finally, can you post the code to your "simple" page that can be observed to eat up memory? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGVDlY9CaO5/Lv0PARAus4AJ9x9vs/Rs8sK2SfOJ99Xn/hH0lnegCePmKU gPOCQmdQ02HzxCmL0L4xen4= =J13G -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serious memory leak
>> What I discovered was that >> a simple page reload leads to eating up my memory and - according to >> the profiler - the memory leak is produced by the constructor of >> java.util.zip.InflaterInputStream allocating more and more byte[] >> objects that cannot be garbage-collected. >Are you sure they cannot be garbage-collected? How do you know? The profiler can perform garbage-collection at any time I press a button. After pressing this, no memory is freed-up :( >> This class deals with >> reading jar files. >Usually, JAR files are read to load class files. When class files are >read, their code needs to be read into memory (in byte arrays). It also >need to stay in memory in order to be executed. It's true, class loading >uses memory ;) But does it load the classes each time I reaload the page? Because (just for testing) I have a simple, static page with only struts tags on it and pressing the reload button eats up some more memory. >> After browsing through about 80-100 pages I get an OutOfMemory >> error... Are you sure these facts are related? Class loading almost never causes a problem unless you are loading millions of classes. Well, I'm not sure, but since my page has "nothing" on it, I don't know what else may cause such thing... and again, it's the profiler that says memory is eaten up by the constructor of InflaterInputstream class. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUuwf9CaO5/Lv0PARAvHKAKDDPuJNP4WIl7xFaLTK/jGES62YcQCffXx9 NGZ9AClOPKuN7KUo1F/Is+U= =oTIF -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121
Re: Serious memory leak
You could also try to run jmap -histo when you get the
OutOfMemoryError; you'll probably see the same as in the NetBeans
profiler but maybe it helps to reveal the "memory eater" anyway.
Torsten
Balazs Michnay wrote:
> Hi,
>
> I have just downloaded NetBeans Profiler to see how my web-app performs and
> realized that it produces serious memory leaks... The interesting part is
> that I have nothing on my JSP but static struts tags (no dynamic content at
> all) and it turned out that the leaks are not made by my application, but
> made by either struts (???) or Tomcat (???) or Java itself, I don't know
> what...
> What I discovered was that a simple page reload leads to eating up my memory
> and - according to the profiler - the memory leak is produced by the
> constructor of java.util.zip.InflaterInputStream allocating more and more
> byte[] objects that cannot be garbage-collected. This class deals with
> reading jar files. If I take a look at the source code I can clearly see that
> it really allocates memory for byte[]:
>
> public InflaterInputStream(InputStream in, Inflater inf, int size) {
> super(in);
> if (in == null || inf == null) {
> throw new NullPointerException();
> } else if (size <= 0) {
> throw new IllegalArgumentException("buffer size <= 0");
> }
> this.inf = inf;
> buf = new byte[size];
> }
>
> After browsing through about 80-100 pages I get an OutOfMemory error...
>
> Interesting, huh?
>
> Where should I ask this? On a Java list? Or does this have anything to do
> with Struts (probably not...)?
> Any ideas why this happens are welcome...
>
> Regards,
>
> BM
>
>
>
>
> Be
> a better Globetrotter. Get better travel answers from someone who knows.
> Yahoo! Answers - Check it out.
> http://answers.yahoo.com/dir/?link=list&sid=396545469
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serious memory leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Balazs, Balazs Michnay wrote: > I have just downloaded NetBeans Profiler to see how my web-app > performs and realized that it produces serious memory leaks... [snip] > What I discovered was that > a simple page reload leads to eating up my memory and - according to > the profiler - the memory leak is produced by the constructor of > java.util.zip.InflaterInputStream allocating more and more byte[] > objects that cannot be garbage-collected. Are you sure they cannot be garbage-collected? How do you know? > This class deals with > reading jar files. Usually, JAR files are read to load class files. When class files are read, their code needs to be read into memory (in byte arrays). It also need to stay in memory in order to be executed. It's true, class loading uses memory ;) > After browsing through about 80-100 pages I get an OutOfMemory > error... Are you sure these facts are related? Class loading almost never causes a problem unless you are loading millions of classes. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUuwf9CaO5/Lv0PARAvHKAKDDPuJNP4WIl7xFaLTK/jGES62YcQCffXx9 NGZ9AClOPKuN7KUo1F/Is+U= =oTIF -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serious memory leak
2007/5/22, Balazs Michnay <[EMAIL PROTECTED]>: Hi, I have just downloaded NetBeans Profiler to see how my web-app performs and realized that it produces serious memory leaks... The interesting part is that I have nothing on my JSP but static struts tags (no dynamic content at all) and it turned out that the leaks are not made by my application, but made by either struts (???) or Tomcat (???) or Java itself, I don't know what... What I discovered was that a simple page reload leads to eating up my memory and - according to the profiler - the memory leak is produced by the constructor of java.util.zip.InflaterInputStream allocating more and more byte[] objects that cannot be garbage-collected. This class deals with reading jar files. If I take a look at the source code I can clearly see that it really allocates memory for byte[]: do you have a stack strace? to see what objects call InflaterInputStream -- Guillaume Carré - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Serious memory leak
Hi,
I have just downloaded NetBeans Profiler to see how my web-app performs and
realized that it produces serious memory leaks... The interesting part is that
I have nothing on my JSP but static struts tags (no dynamic content at all) and
it turned out that the leaks are not made by my application, but made by either
struts (???) or Tomcat (???) or Java itself, I don't know what...
What I discovered was that a simple page reload leads to eating up my memory
and - according to the profiler - the memory leak is produced by the
constructor of java.util.zip.InflaterInputStream allocating more and more
byte[] objects that cannot be garbage-collected. This class deals with reading
jar files. If I take a look at the source code I can clearly see that it really
allocates memory for byte[]:
public InflaterInputStream(InputStream in, Inflater inf, int size) {
super(in);
if (in == null || inf == null) {
throw new NullPointerException();
} else if (size <= 0) {
throw new IllegalArgumentException("buffer size <= 0");
}
this.inf = inf;
buf = new byte[size];
}
After browsing through about 80-100 pages I get an OutOfMemory error...
Interesting, huh?
Where should I ask this? On a Java list? Or does this have anything to do with
Struts (probably not...)?
Any ideas why this happens are welcome...
Regards,
BM
Be
a better Globetrotter. Get better travel answers from someone who knows.
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469
