lbehnke / h2database

Automatically exported from code.google.com/p/h2database
0 stars 0 forks source link

AUTO_SERVER=TRUE doesn't use daemon thread - hangs tomcat exit #188

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Before submitting a bug, please check the FAQ:
http://www.h2database.com/html/faq.html

What steps will reproduce the problem?
(simple SQL scripts or simple standalone applications are preferred)
1. From Tomcat, connect to an h2 connection with AUTO_SERVER=TRUE in the
jdbc URL
2. Try to stop tomcat using normal tomcat stop script

Tomcat will hang because the TcpServer doesn't call setDaemon(true) on the
thread it creates

What is the expected output? What do you see instead?
N/A

What version of the product are you using? On what operating system, file
system, and virtual machine?
Windows 7, 64bit, within Tomcat 5.5, h2 version 1.2.133

Do you know a workaround?
No

How important/urgent is the problem for you?
Critical

In your view, is this a defect or a feature request?
Defect

Please provide any additional information below.
Since h2 threads are all server-type threads, they should definitely all be
set to daemon mode. Changes should actually be made minimally to
TcpServer.java, PgServer.java, and Server.java

Thanks,

Marc

Original issue reported on code.google.com by mbOrches...@gmail.com on 14 Apr 2010 at 2:13

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
Fixed in version 1.2.134

Original comment by thomas.t...@gmail.com on 23 Apr 2010 at 5:25