Closed GoogleCodeExporter closed 9 years ago
Note - I modified the classes mentioned on my machine, rebuilt, and was able to
stop
tomcat without problem. Changes:
TcpServer.java - added line 214 - thread.setDaemon(true);
PgServer.java - added line 170 - thread.setDaemon(true);
Server.java - added line 332 - t.setDaemon(true);
Original comment by mbOrches...@gmail.com
on 14 Apr 2010 at 2:43
Hi,
>> Do you know a workaround?
> No
Did you close the database? If not, why not, or why is that not a good solution?
Original comment by thomas.t...@gmail.com
on 16 Apr 2010 at 8:03
I have no control to do that. You define the connection information in the
server.xml
or the context.xml. This sets them up as JNDI data sources. Getting a
connection from
the datasource is a conn = ds.getConnection(); and that will return the
connection
from the pool. Doing the commensurate conn.close() doesn't close the physical
connection, instead it's added back to the connection pool.
When Tomcat is told to shutdown, it blocks waiting on the thread. I checked out
and
modified it to use setDaemon(true) in Server.java, PgServer.java, and
TcpServer.java.
I was then able to re-run the test and confirm that tomcat shuts down properly.
Original comment by mbOrches...@gmail.com
on 16 Apr 2010 at 11:03
Hi,
The physical connection should be closed using PooledConnection.close(). The
connection pool should call it when the connection pool is disposed (when using
the
built-in connection pool this happens when calling
JdbcConnectionPool.dispose()).
What connection pool do you use, and how does your configuration look like
(server.xml or context.xml)?
Of course adding setDaemon(true) solves the problem, and I might add that, but
it
will break other things (for example the H2 Console, and maybe user
applications).
That's why I would like to avoid changing this. Adding as an optional feature is
possible, but it may unnecessarily complicate things.
Original comment by thomas.t...@gmail.com
on 16 Apr 2010 at 11:45
Hi Thomas,
Just so we understand each other - I'm not using a connection pool, Tomcat is
(DBCP).
I'm not creating or destroying the pool, Tomcat is. I'm not in control, Tomcat
is. ;-)
Following the Tomcat documentation (
http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html ),
the
context.xml for my web application had the following definition:
<Resource name="jdbc/GettingStartedDB" auth="Container"
type="javax.sql.DataSource"
factory="org.apache.commons.dbcp.BasicDataSourceFactory" maxActive="5" maxIdle="2"
maxWait="10000" username="sa" password=""
driverClassName="com.h2.Driver"
url="jdbc:h2:/folder/GettingStartedDB/GettingStarted;AUTO_SERVER=TRUE"
validationQuery="select 1 from dual"/>
The web application would happily startup and create the required folders and a
GettingStarted.h2.db file. Launching the tomcat stop script however hung tomcat
waiting for the thread to stop.
I'd be thrilled with a AUTO_DAEMON_SERVER=true flag - that makes sense in this
context. It's clean, and doesn't affect the standard path for all others using
the
server in that manner. I don't use PgServer.java so I'm not affected by not
changing
it. But, I'd suggest that there be an argument that could be passed to those
static
methods that would allow the developer to inject the setDaemon when needed.
From the
outside, we can't get at the thread, and we can't subclass to alter the
behavior.
Original comment by mbOrches...@gmail.com
on 16 Apr 2010 at 12:00
Maybe the best solution is to add a "deamon" option when starting the various
server,
and use this option when using AUTO_SERVER=TRUE.
Original comment by thomas.t...@gmail.com
on 19 Apr 2010 at 7:11
Hi,
Tomcat 6.0 does stop (both with and without daemon threads), but writes this to
the
log file (in both cases):
SEVERE: A web application appears to have started a thread named [H2 File Lock
Watchdog /Users/tmueller/Desktop/test.lock.db] but has failed to stop it. This
is
very likely to create a memory leak.
Apr 20, 2010 3:48:00 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named [H2 TCP Server
(tcp://10.10.1.174:56293)] but has failed to stop it. This is very likely to
create a
memory leak.
Apr 20, 2010 3:48:00 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: A web application appears to have started a thread named [H2 Log Writer
TEST]
but has failed to stop it. This is very likely to create a memory leak.
Whether or not the threads are daemon threads or not. For me, that's a bug in
Tomcat
(Tomcat doesn't dispose the connection pool). I don't think it is possible to
fix
that within H2.
Configuration in Tomcat 6.0:
context.xml
<Resource
name="jdbc/GettingStartedDB"
auth="Container"
type="javax.sql.DataSource"
maxActive="100" maxIdle="30" maxWait="10000"
username="sa"
password="sa"
driverClassName="org.h2.Driver"
url="jdbc:h2:~/Desktop/test;AUTO_SERVER=TRUE"
/>
Regards,
Thomas
Original comment by thomas.t...@gmail.com
on 20 Apr 2010 at 6:47
Fixed in version 1.2.134
Original comment by thomas.t...@gmail.com
on 23 Apr 2010 at 5:25
Original issue reported on code.google.com by
mbOrches...@gmail.com
on 14 Apr 2010 at 2:13