You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Samer Kanjo <sa...@kanjo.net> on 2005/10/23 01:58:49 UTC
AntiGC Not Shutting Down
I am running Derby server inside my web application which is running in
Tomcat 5. I need to run Derby as a server in order to allow batch processes
and the web application to access the database. What I have discovered is
that shutting down Derby from within my web application does not completely
shutdown Derby, the AntiGC thread continues to run.
I checked the mailing list archives and found no references to AntiGC. I
then checked the derby bugs list and found bug 23 which indicated a memory
leak and a suggested fix that was applied. However the bug has been
re-opened due to continuing problems. The problems that were identified had
to do with the embedded driver. I wanted to mention that I am having
problems with the server as well. I was previously using 10.1.1.0 and
switched to 10.1.1.1 due to the patch but found that the problem did in fact
persist.
When I do shutdown Derby the following 2 threads remain:
Thread [derby.antiGC] (Running)
Thread [derby.rawStoreDaemon] (Running)
When Derby is running I see the following threads:
Thread [derby.NetworkServerStarter] (Running)
Thread [Thread-40] (Running)
Thread [DRDAConnThread_41] (Running)
Thread [derby.antiGC] (Running)
Thread [derby.rawStoreDaemon] (Running)
So far the only consequences of this problem for me are the inability to
remotely shutdown the application and redeploy using the Tomcat Manager.
Re: AntiGC Not Shutting Down
Posted by sa...@kanjo.net.
Eric,
I checked out the link and followed the casual scenario and was able to fully
undeploy and re-deploy my app using Tomcat Manager however after re-deployment
derby will not restart.
I need to spend some time looking into this further. I think I should also
consider using the enterprise scenario.
Thanks,
Samer
Re: AntiGC Not Shutting Down
Posted by Knut Anders Hatlen <Kn...@sun.com>.
Eric Lenio <er...@lenio.net> writes:
> On Mon, Oct 24, 2005 at 10:54:37AM +0200, Knut Anders Hatlen wrote:
>> Eric Lenio <er...@lenio.net> writes:
>>
>> > I have a similar setup as you, and previously I had witnessed similar
>> > behavior with AntiGC. I recommend this link if you haven't already seen
>> > it:
>> >
>> > http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0508bader/
>> >
>> > Be especially sure to put derby.jar in the correct path. In my case the
>> > AntiGC thread issue went away when derby.jar was placed in
>> > tomcat/common/lib (like the above article states in the "casual
>> > scenario" section). The embedded and network drivers worked perfectly
>> > after I did this. Hope this helps.
>>
>> Hi Eric,
>>
>> Are you running the official Apache Derby 10.1.1.0 or the patched
>> version I sent you?
>>
>
> Hi Knut, yes I am indeed using your patched version which has run very
> stable for me. I've been stress testing my Tomcat application for
> several weeks now without having to restart Tomcat or Derby even once,
> whereas before I had to restart several times per hour during heavy
> development.
Then I guess the original poster has to use the development version or
patch and build his own 10.1 jar in order to solve the problem.
> I would also add that there *may* be another thread issue with
> DRDAConnThread, I've been monitoring Tomcat with Jconsole for a while
> now and these types of threads seem to be growing (I've got 11 right
> now, but haven't touched the database in 24 hours). I have no idea
> about what DRDAConnThread even does, so maybe what I am witnessing is
> normal.
The network server has one DRDAConnThread for each client which is
connected. DRDAConnThreads can be reused, but DERBY-206 states that
"[unless] derby.drda.maxThreads parameter is set the number of
DRDAConnThreads will be equal to the maximum number of simultaneous
connections ever and there is no way to free the memory without
shutting down and restarting the server."
As long as the network server is running, seeing a non-decreasing
number of DRDAConnThreads is normal, but if you see DRDAConnThreads
even after you have unloaded the Derby driver, I would say it's a bug.
--
Knut Anders
Re: AntiGC Not Shutting Down
Posted by Eric Lenio <er...@lenio.net>.
On Mon, Oct 24, 2005 at 10:54:37AM +0200, Knut Anders Hatlen wrote:
> Eric Lenio <er...@lenio.net> writes:
>
> > I have a similar setup as you, and previously I had witnessed similar
> > behavior with AntiGC. I recommend this link if you haven't already seen
> > it:
> >
> > http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0508bader/
> >
> > Be especially sure to put derby.jar in the correct path. In my case the
> > AntiGC thread issue went away when derby.jar was placed in
> > tomcat/common/lib (like the above article states in the "casual
> > scenario" section). The embedded and network drivers worked perfectly
> > after I did this. Hope this helps.
>
> Hi Eric,
>
> Are you running the official Apache Derby 10.1.1.0 or the patched
> version I sent you?
>
Hi Knut, yes I am indeed using your patched version which has run very
stable for me. I've been stress testing my Tomcat application for
several weeks now without having to restart Tomcat or Derby even once,
whereas before I had to restart several times per hour during heavy
development.
I would also add that there *may* be another thread issue with
DRDAConnThread, I've been monitoring Tomcat with Jconsole for a while
now and these types of threads seem to be growing (I've got 11 right
now, but haven't touched the database in 24 hours). I have no idea
about what DRDAConnThread even does, so maybe what I am witnessing is
normal.
Eric.
Re: AntiGC Not Shutting Down
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Eric Lenio <er...@lenio.net> writes:
> I have a similar setup as you, and previously I had witnessed similar
> behavior with AntiGC. I recommend this link if you haven't already seen
> it:
>
> http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0508bader/
>
> Be especially sure to put derby.jar in the correct path. In my case the
> AntiGC thread issue went away when derby.jar was placed in
> tomcat/common/lib (like the above article states in the "casual
> scenario" section). The embedded and network drivers worked perfectly
> after I did this. Hope this helps.
Hi Eric,
Are you running the official Apache Derby 10.1.1.0 or the patched
version I sent you?
--
Knut Anders
Re: AntiGC Not Shutting Down
Posted by Eric Lenio <er...@lenio.net>.
I have a similar setup as you, and previously I had witnessed similar
behavior with AntiGC. I recommend this link if you haven't already seen
it:
http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0508bader/
Be especially sure to put derby.jar in the correct path. In my case the
AntiGC thread issue went away when derby.jar was placed in
tomcat/common/lib (like the above article states in the "casual
scenario" section). The embedded and network drivers worked perfectly
after I did this. Hope this helps.
On Sat, Oct 22, 2005 at 06:58:49PM -0500, Samer Kanjo wrote:
> I am running Derby server inside my web application which is running
> in Tomcat 5. I need to run Derby as a server in order to allow batch
> processes and the web application to access the database. What I have
> discovered is that shutting down Derby from within my web application
> does not completely shutdown Derby, the AntiGC thread continues to
> run.
>
>
> I checked the mailing list archives and found no references to AntiGC.
> I then checked the derby bugs list and found bug 23 which indicated a
> memory leak and a suggested fix that was applied. However the bug has
> been re-opened due to continuing problems. The problems that were
> identified had to do with the embedded driver. I wanted to mention
> that I am having problems with the server as well. I was previously
> using 10.1.1.0 and switched to 10.1.1.1 due to the patch but found
> that the problem did in fact persist.
>
>
> When I do shutdown Derby the following 2 threads remain:
>
> Thread [derby.antiGC] (Running)
>
> Thread [derby.rawStoreDaemon] (Running)
>
>
> When Derby is running I see the following threads:
>
> Thread [derby.NetworkServerStarter] (Running)
>
> Thread [Thread-40] (Running)
>
> Thread [DRDAConnThread_41] (Running)
>
> Thread [derby.antiGC] (Running)
>
> Thread [derby.rawStoreDaemon] (Running)
>
>
>
> So far the only consequences of this problem for me are the inability
> to remotely shutdown the application and redeploy using the Tomcat
> Manager.
RE: AntiGC Not Shutting Down
Posted by Samer Kanjo <sa...@kanjo.net>.
Knut,
Light dawns on marble head!
I somehow missed that important piece of knowledge (shutting down the server
AND the databases) while using the nserverdemo.NsSample demo as a reference
for my implementation.
Shutting down the databases before shutting down the server has solved all
of my problems.
Now I can keep my setup the way it is. No need to move the derby library
files to the tomcat\common\lib folder. After reading the Enterprise scenario
Eric suggested I may change the setup but for now it remains.
FYI: I am now using 10.1.1.1.
Thanks,
Samer Kanjo
Re: AntiGC Not Shutting Down
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
samer@kanjo.net writes:
> I do not receive any errors when starting the database using
> NetworkServerControl.start method. I also shutdown the database using
> NetworkServerControl.shutdown method. I do receive a socket error when
> shutting
> down, which seems to be used to indicate the successful shutdown of
> the server.
NetworkServerControl.shutdown() doesn't shut down the database, only
the network server. That explains why AntiGC and RawStoreDaemon are
still running.
> The server is started and shutdown within the same JVM instance as my
> application. This is not ideal but I am forced to do so if I want to have any
> control over an environment in which I have extremely limited control.
If the application is supposed to access the database (using the
embedded driver) after you have called
NetworkServerControl.shutdown(), AntiGC and RawStoreDaemon should
continue running. Otherwise, you need to unload the Derby driver.
You have (at least) three options:
1. NetworkServerControl.shutdown() stops the network server (listener
and all DRDAConnThreads).
2. DriverManager.getConnection("jdbc:derby:databasename;shutdown=true")
will close the database "databasename" and stop the RawStoreDaemon
thread started by that database. RawStoreDaemons started by other
databases and AntiGC are not stopped.
3. DriverManager.getConnection("jdbc:derby:;shutdown") closes all
databases and stops AntiGC and all RawStoreDaemons.
--
Knut Anders
Re: AntiGC Not Shutting Down
Posted by sa...@kanjo.net.
Quoting Knut Anders Hatlen <Kn...@Sun.COM>:
> The patch is not applied to the 10.1 branch because of some minor
> problems (NullPointerException can be printed to console when you shut
> down Derby, but your application will continue to work). If you want
> to try the fix, you can either download a snapshot of the development
> version (http://www.multinet.no/~solberg/public/Apache/Derby/builds/)
> or download the 10.1 sources and apply the patch yourself.
>
I see, I thought it had been applied in 10.1.1.1. Well that would explain why
the problem persisted. I will consider making my own build. I am also
investigating Eric's suggestion to move the derby libraries to the Tomcat
common folder.
>> When I do shutdown Derby the following 2 threads remain:
>>
>> Thread [derby.antiGC] (Running)
>>
>> Thread [derby.rawStoreDaemon] (Running)
>
> The only time I have seen that the rawStoreDaemon has continued to run
> after a shutdown, is when an error has occurred during the booting of
> a database (e.g., invalid encryption password or wrong log device when
> performing recovery). I have however seen rawStoreDaemons not being
> garbage collected after they have been stopped.
>
> How did you shut down Derby? Did you use
> DriverManager.getConnection("jdbc:derby:;shutdown=true")? If you want
> to shut down Derby entirely, there should be no database name in the
> URL.
>
I do not receive any errors when starting the database using
NetworkServerControl.start method. I also shutdown the database using
NetworkServerControl.shutdown method. I do receive a socket error when
shutting
down, which seems to be used to indicate the successful shutdown of the
server.
The server is started and shutdown within the same JVM instance as my
application. This is not ideal but I am forced to do so if I want to have any
control over an environment in which I have extremely limited control.
Re: Garbage Collector and memory
Posted by Daniel Noll <da...@nuix.com.au>.
Juan Ignacio Villa wrote:
>Hello.
>
>My java application uses memory more and more until it
>crash. It is strange because not use new variables nor
>I do not create them dynamically. I have an for with
>which I make select SQL by means of inserted dynamic
>values. The peculiar thing is that in each return of
>for for, the program uses memory more and more, but I
>do not create new variables, but reusing same
>variables. I proved to garbage it with runtime.gc but
>there was no difference. Dont free it.
>
>
There are a number of things going on here.
As it says in the Java documentation, Runtime.gc() is not guaranteed to
do anything in the first place. Use of the call is usually a sign of
bad code.
>The used memory comes from another part?
>
>
If you run this code twice in a row, does the total used memory
increase? If it doesn't, then it may just be Derby's cache taking up
the memory.
If you get an OutOfMemoryError then obviously there is a real problem.
But if you're getting a crash, then there might be some other problem,
perhaps related to the specific JVM you're running.
>My code is:
>
>Class.forName"org.apache...");
>java.sql.Connection DbConexion =
>DriverManager.getConnection("jdbc:derby:" + addpath
>+"/prueba....");
>
>String sql ="";
>Statement Consulta =null;
>ResultSet Rs = null;
>
>for (int i=1; i<400; i++) {
> sql="SELECT * FROM tipo2 WHERE " + consul[i];
> Consulta =
>DBConexion.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_UPDATABLE);
> Rs = Consulta.executeQuery(sql);
> Rs.close();
> Rs = null;
> Consulta.close();
> Consulta = null;
>}
>
>try{
> Rs.close();
> Consulta.close();
> Rs = null;
> Consulta = null;
>}catch(...)
>
>
There are a number of issues with the above code, but fixing the issues
wouldn't necessarily fix this issue anyway. Ignoring the code style for
now (variables start with a lower-case letter, references don't need to
be assigned to null a few nanoseconds before they're about to be
assigned to again, etc.), the code above is extremely bad at handling
bad conditions.
Written properly, the code above would look more like:
Statement statement =
connection.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,
ResultSet.CONCURT_UPDATABLE);
try {
for (int i = 1; i < 400; i++) { // <-- looping from 1 to 399 is
weird in itself.
String sql = ...
ResultSet rs = statement.executeQuery(sql);
try {
// Do stuff with rs.
} finally {
try {
rs.close();
} catch (SQLException e) { /* ignore or log */ }
}
}
} finally {
try {
statement.close();
} catch (SQLException e) { /* ignore or log */ }
}
The reason for the use of finally here is that if your code on the
inside threw an exception, then nothing would have been closed. That
would be guaranteed to cause memory leaks like what you describe, but
only in the event of errors.
And of course, this reuses the same statement, because creating multiple
statements when you only actually need one is wasteful.
Daniel
--
Daniel Noll
NUIX Pty Ltd
Level 8, 143 York Street, Sydney 2000
Phone: (02) 9283 9010
Fax: (02) 9283 9020
This message is intended only for the named recipient. If you are not
the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
message or attachment is strictly prohibited.
Re: Garbage Collector and memory
Posted by Dy...@Sun.COM.
Juan Ignacio Villa <ji...@yahoo.es> writes:
> Hello.
>
> My java application uses memory more and more until it
> crash. It is strange because not use new variables nor
> I do not create them dynamically. I have an for with
> which I make select SQL by means of inserted dynamic
> values. The peculiar thing is that in each return of
> for for, the program uses memory more and more, but I
> do not create new variables, but reusing same
> variables. I proved to garbage it with runtime.gc but
> there was no difference. Dont free it.
>
> I can do it of other way, but I have discovered that
> gc does not work to me in the application. It does not
> release memory until the application finalizes, and
> cannot be in a server application.
> It is necessary to make some extra task to release
> statements, resultsets or connections?
> The used memory comes from another part?
>
> derbydev.pdf tells that the memory to gc is closed
> normally. Also I have seen that driver it maintains a
> list of resultset not closed and does not release the
> memory.
>
> My code is:
>
> Class.forName"org.apache...");
> java.sql.Connection DbConexion =
> DriverManager.getConnection("jdbc:derby:" + addpath
> +"/prueba....");
>
> String sql ="";
> Statement Consulta =null;
> ResultSet Rs = null;
>
> for (int i=1; i<400; i++) {
> sql="SELECT * FROM tipo2 WHERE " + consul[i];
// This creates a new dynamic object
> Consulta =
> DBConexion.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_UPDATABLE);
// ... as does this
> Rs = Consulta.executeQuery(sql);
// .. and this
> Rs.close();
> Rs = null;
> Consulta.close();
> Consulta = null;
> }
>
> try{
> Rs.close();
> Consulta.close();
> Rs = null;
> Consulta = null;
> }catch(...)
>
Try using prepared statements instead. That is something like (untested):
PreparedStatement Consulta = DBConnexion.prepareStatement("SELECT *
FROM tipo2 WHERE <someColumn> <op> ?");
// Replace <someColumn> and <op> as appropriate
for (int i=1; i<400; i++) {
Consulta.set<Type>(1, consul[i]); // Replace <Type> with the type of consul[i]
Rs = Consulta.executeQuery();
// Do something with Rs ??
Rs.close();
}
--
dt
However, experience shows that for many people and many applications a
dose of paranoia is reasonable - Bjarne Stroustrup
Re: Garbage Collector and memory
Posted by Dy...@Sun.COM.
Juan Ignacio Villa <ji...@yahoo.es> writes:
> Thanks.
> I resolve it. But i dont mind the difference between
> rs.executeQuery() and rs.executeQuery(sql). Whith the
> fist one i get the outOfMemory exception.
Well, as long as it works for you...
But compiling the statement each time you go through the loop will
degrade performance. I don't understand why you should get an
out-of-memory error when you use prepared statements, though...
--
dt
Re: Garbage Collector and memory
Posted by Juan Ignacio Villa <ji...@yahoo.es>.
Thanks.
I resolve it. But i dont mind the difference between
rs.executeQuery() and rs.executeQuery(sql). Whith the
fist one i get the outOfMemory exception.
class.forName("org.apache...");
Connnection DBcon =
DriverManager.getConnection("jdbc:derby:....");
String Sql = "";
Statement Consulta
=DBcon.createStatement(ResultSet.TYPE_SCROLL_INSENTISIVE,
ResultSet.CONCUR_READ_ONLY);
try
{
for (int i =1; i< 5000; i++)
{
Sql = "Select .... from... where..."; //use of
variables to make a lof of queries.
ResultSet rs = Consulta.executeQuery(Sql);
try
{
//rs management.
}
catch (.....
}
try
{
Consulta.close();
DBcon.close();
System.gc();
System.gc();
}
catch ...
//Greeting to all.
--- ji_villa <ji...@yahoo.es> escribió:
> El mar, 25-10-2005 a las 13:56 +0200, Fernanda
> Pizzorno escribió:
> > Juan Ignacio Villa wrote:
> >
> > >[...]
> > >
> > > Consulta =
> >
>
>DBConexion.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_UPDATABLE);
> > > Rs = Consulta.executeQuery(sql);
> > >
> > >[...]
> > >
> > Hello,
> >
> > Scrollable sensitive result sets
> (ResultSet.TYPE_SCROLL_SENSITIVE) are
> > not implemented
> > in Derby. Scrollable insensitive result sets
> > (ResultSet.TYPE_SCROLL_INSENSITIVE) are
> > implemented in Derby, but only with concurrency
> ResultSet.CONCUR_READ_ONLY.
> >
> > If your application needs updatable result sets
> (ie. if you are going to
> > use updateXXX,
> > updateRow(), insertRow() or deleteRow() methods),
> you will have to use
> > forward only result
> > sets (ResultSet.TYPE_FORWARD_ONLY), and you will
> only be able to move
> > between rows in the
> > result set using next().
> >
> > On the other hand, if you do not need to use
> updatable result sets, you
> > can use scrollable
> > insensitive result sets. The difference between
> this type and the one
> > you are using is that
> > it is not sensitive to changes to the underlying
> table.
> >
> > Since the result set type and concurrency you are
> trying to use are not
> > implemented in
> > Derby, the driver will generate a SQLWarning. And
> you can check the type
> > and concurrency
> > of the result set returned by the driver using
> ResultSet.getType() and
> > ResultSet.getConcurrency() respectively.
> >
> > Fernanda
> >
>
> Thanks Fernanda. But i prove with
> ResultSet.TYPE_SCROLL_INSENSITIVE and
> ResultSet.CONCUR_READ_ONLY and i get an out of
> memory error too.
> Only works fine with ResultSet.TYPE_FORWARD_ONLY.
>
> Statements or preparedStatements fail equals. Both
> give me the out of
> memory error.
>
> The code of Dyre (thaks Dyre) fails too.
>
> System.gc also not free memory.
> Catch exceptions not solve it.
> Yes, bad code.
>
> I am proving to resolve it.
> ¿Is extrange? Would be.
>
> ...and very thanks.
>
> Villa.
>
______________________________________________
Renovamos el Correo Yahoo!
Nuevos servicios, más seguridad
http://correo.yahoo.es
Re: Garbage Collector and memory
Posted by ji_villa <ji...@yahoo.es>.
El mar, 25-10-2005 a las 13:56 +0200, Fernanda Pizzorno escribió:
> Juan Ignacio Villa wrote:
>
> >[...]
> >
> > Consulta =
> >DBConexion.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_UPDATABLE);
> > Rs = Consulta.executeQuery(sql);
> >
> >[...]
> >
> Hello,
>
> Scrollable sensitive result sets (ResultSet.TYPE_SCROLL_SENSITIVE) are
> not implemented
> in Derby. Scrollable insensitive result sets
> (ResultSet.TYPE_SCROLL_INSENSITIVE) are
> implemented in Derby, but only with concurrency ResultSet.CONCUR_READ_ONLY.
>
> If your application needs updatable result sets (ie. if you are going to
> use updateXXX,
> updateRow(), insertRow() or deleteRow() methods), you will have to use
> forward only result
> sets (ResultSet.TYPE_FORWARD_ONLY), and you will only be able to move
> between rows in the
> result set using next().
>
> On the other hand, if you do not need to use updatable result sets, you
> can use scrollable
> insensitive result sets. The difference between this type and the one
> you are using is that
> it is not sensitive to changes to the underlying table.
>
> Since the result set type and concurrency you are trying to use are not
> implemented in
> Derby, the driver will generate a SQLWarning. And you can check the type
> and concurrency
> of the result set returned by the driver using ResultSet.getType() and
> ResultSet.getConcurrency() respectively.
>
> Fernanda
>
Thanks Fernanda. But i prove with ResultSet.TYPE_SCROLL_INSENSITIVE and
ResultSet.CONCUR_READ_ONLY and i get an out of memory error too.
Only works fine with ResultSet.TYPE_FORWARD_ONLY.
Statements or preparedStatements fail equals. Both give me the out of
memory error.
The code of Dyre (thaks Dyre) fails too.
System.gc also not free memory.
Catch exceptions not solve it.
Yes, bad code.
I am proving to resolve it.
¿Is extrange? Would be.
...and very thanks.
Villa.
Re: Garbage Collector and memory
Posted by Fernanda Pizzorno <Fe...@Sun.COM>.
Juan Ignacio Villa wrote:
>[...]
>
> Consulta =
>DBConexion.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_UPDATABLE);
> Rs = Consulta.executeQuery(sql);
>
>[...]
>
Hello,
Scrollable sensitive result sets (ResultSet.TYPE_SCROLL_SENSITIVE) are
not implemented
in Derby. Scrollable insensitive result sets
(ResultSet.TYPE_SCROLL_INSENSITIVE) are
implemented in Derby, but only with concurrency ResultSet.CONCUR_READ_ONLY.
If your application needs updatable result sets (ie. if you are going to
use updateXXX,
updateRow(), insertRow() or deleteRow() methods), you will have to use
forward only result
sets (ResultSet.TYPE_FORWARD_ONLY), and you will only be able to move
between rows in the
result set using next().
On the other hand, if you do not need to use updatable result sets, you
can use scrollable
insensitive result sets. The difference between this type and the one
you are using is that
it is not sensitive to changes to the underlying table.
Since the result set type and concurrency you are trying to use are not
implemented in
Derby, the driver will generate a SQLWarning. And you can check the type
and concurrency
of the result set returned by the driver using ResultSet.getType() and
ResultSet.getConcurrency() respectively.
Fernanda
Garbage Collector and memory
Posted by Juan Ignacio Villa <ji...@yahoo.es>.
Hello.
My java application uses memory more and more until it
crash. It is strange because not use new variables nor
I do not create them dynamically. I have an for with
which I make select SQL by means of inserted dynamic
values. The peculiar thing is that in each return of
for for, the program uses memory more and more, but I
do not create new variables, but reusing same
variables. I proved to garbage it with runtime.gc but
there was no difference. Dont free it.
I can do it of other way, but I have discovered that
gc does not work to me in the application. It does not
release memory until the application finalizes, and
cannot be in a server application.
It is necessary to make some extra task to release
statements, resultsets or connections?
The used memory comes from another part?
derbydev.pdf tells that the memory to gc is closed
normally. Also I have seen that driver it maintains a
list of resultset not closed and does not release the
memory.
My code is:
Class.forName"org.apache...");
java.sql.Connection DbConexion =
DriverManager.getConnection("jdbc:derby:" + addpath
+"/prueba....");
String sql ="";
Statement Consulta =null;
ResultSet Rs = null;
for (int i=1; i<400; i++) {
sql="SELECT * FROM tipo2 WHERE " + consul[i];
Consulta =
DBConexion.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_UPDATABLE);
Rs = Consulta.executeQuery(sql);
Rs.close();
Rs = null;
Consulta.close();
Consulta = null;
}
try{
Rs.close();
Consulta.close();
Rs = null;
Consulta = null;
}catch(...)
Variable declarations must be into for, but result is
the same.
Greetins.
______________________________________________
Renovamos el Correo Yahoo!
Nuevos servicios, más seguridad
http://correo.yahoo.es
Re: AntiGC Not Shutting Down
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Samer Kanjo <sa...@kanjo.net> writes:
> I am running Derby server inside my web application which is running
> in Tomcat 5. I need to run Derby as a server in order to allow batch
> processes and the web application to access the database. What I
> have discovered is that shutting down Derby from within my web
> application does not completely shutdown Derby, the AntiGC thread
> continues to run.
>
> I checked the mailing list archives and found no references to
> AntiGC. I then checked the derby bugs list and found bug 23 which
> indicated a memory leak and a suggested fix that was
> applied. However the bug has been re-opened due to continuing
> problems. The problems that were identified had to do with the
> embedded driver. I wanted to mention that I am having problems with
> the server as well. I was previously using 10.1.1.0 and switched to
> 10.1.1.1 due to the patch but found that the problem did in fact
> persist.
The patch is not applied to the 10.1 branch because of some minor
problems (NullPointerException can be printed to console when you shut
down Derby, but your application will continue to work). If you want
to try the fix, you can either download a snapshot of the development
version (http://www.multinet.no/~solberg/public/Apache/Derby/builds/)
or download the 10.1 sources and apply the patch yourself.
> When I do shutdown Derby the following 2 threads remain:
>
> Thread [derby.antiGC] (Running)
>
> Thread [derby.rawStoreDaemon] (Running)
The only time I have seen that the rawStoreDaemon has continued to run
after a shutdown, is when an error has occurred during the booting of
a database (e.g., invalid encryption password or wrong log device when
performing recovery). I have however seen rawStoreDaemons not being
garbage collected after they have been stopped.
How did you shut down Derby? Did you use
DriverManager.getConnection("jdbc:derby:;shutdown=true")? If you want
to shut down Derby entirely, there should be no database name in the
URL.
--
Knut Anders