date:20120404

Hi,

I am using Tomcat 7.0.25 in a Linux machine

I am using Tomcat's connection pool 
(org.apache.tomcat.dbcp.dbcp.BasicDataSource). As database I am using H2 as a 
file database.
All is ok, but I have the following problem.
On shutdown of Tomcat I see in catalina.out: 


SEVERE: The web application [/GeneralApplication] appears to have started a 
thread named [H2 Log Writer GENERICAPPLICATION] but has failed to stop it. This 
is very likely to create a memory leak.
Apr 4, 2012 2:32:54 PM org.apache.catalina.loader.WebappClassLoader 
clearReferencesThreads
SEVERE: The web application [/GeneralApplication] appears to have started a 
thread named [H2 File Lock Watchdog 
/opt/en/repos/tomcat/webapps/GeneralApplication/db/internaldatabase.lock.db] 
but has failed to stop it. This is very likely to create a memory leak.

Why do I get these messages?
As I understand these messages, H2 is still running on shutdown and the 
documentation they have says that the database will shutdown once the last 
connection is closed (and the connections are handled by the pool i.e. Tomcat)

Additionally the input from H2 dev is that these messages are a Tomcat problem. 
Tomcat should have first disposed of the connection pool and then log the 
running threads.Their explanation seem correct to me.

Is this a known issue? Why do I see these errors in catalina? Should I somehow 
dispose off the connection pool myself?

Thank you for your time
Best Regards,
FH

Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks

2012-04-04 Thread Daniel Mikusa



- Original Message -
 Hi,
 
 I am using Tomcat 7.0.25 in a Linux machine
 
 I am using Tomcat's connection pool
 (org.apache.tomcat.dbcp.dbcp.BasicDataSource). As database I am
 using H2 as a file database.

Where are you defining the connection pool?  Can you include your configuration?

Dan


 All is ok, but I have the following problem.
 On shutdown of Tomcat I see in catalina.out:
 
 
 SEVERE: The web application [/GeneralApplication] appears to have
 started a thread named [H2 Log Writer GENERICAPPLICATION] but has
 failed to stop it. This is very likely to create a memory leak.
 Apr 4, 2012 2:32:54 PM org.apache.catalina.loader.WebappClassLoader
 clearReferencesThreads
 SEVERE: The web application [/GeneralApplication] appears to have
 started a thread named [H2 File Lock Watchdog
 /opt/en/repos/tomcat/webapps/GeneralApplication/db/internaldatabase.lock.db]
 but has failed to stop it. This is very likely to create a memory
 leak.
 
 Why do I get these messages?
 As I understand these messages, H2 is still running on shutdown and
 the documentation they have says that the database will shutdown
 once the last connection is closed (and the connections are handled
 by the pool i.e. Tomcat)
 
 Additionally the input from H2 dev is that these messages are a
 Tomcat problem. Tomcat should have first disposed of the connection
 pool and then log the running threads.Their explanation seem correct
 to me.
 
 Is this a known issue? Why do I see these errors in catalina? Should
 I somehow dispose off the connection pool myself?
 
 Thank you for your time
 Best Regards,
 FH
 

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks

2012-04-04 Thread Pid

On 04/04/2012 13:05, Hermes Flying wrote:
 Hi,
 
 I am using Tomcat 7.0.25 in a Linux machine
 
 I am using Tomcat's connection pool 
 (org.apache.tomcat.dbcp.dbcp.BasicDataSource). As database I am using H2 as a 
 file database.
 All is ok, but I have the following problem.
 On shutdown of Tomcat I see in catalina.out: 

In which file have you defined the pool?


 SEVERE: The web application [/GeneralApplication] appears to have started a 
 thread named [H2 Log Writer GENERICAPPLICATION] but has failed to stop it. 
 This is very likely to create a memory leak.
 Apr 4, 2012 2:32:54 PM org.apache.catalina.loader.WebappClassLoader 
 clearReferencesThreads
 SEVERE: The web application [/GeneralApplication] appears to have started a 
 thread named [H2 File Lock Watchdog 
 /opt/en/repos/tomcat/webapps/GeneralApplication/db/internaldatabase.lock.db] 
 but has failed to stop it. This is very likely to create a memory leak.
 
 Why do I get these messages?

When the application shuts down Tomcat tries to detect  prevent memory
leaks by examining threads  various things associated with the
WebappClassloader.


 As I understand these messages, H2 is still running on shutdown and the 
 documentation they have says that the database will shutdown once the last 
 connection is closed (and the connections are handled by the pool i.e. Tomcat)

So there is no way to manually the database down?


 Additionally the input from H2 dev is that these messages are a Tomcat 
 problem. Tomcat should have first disposed of the connection pool and then 
 log the running threads.Their explanation seem correct to me.

That's the usual first response.  Let's figure out whether it's correct...


 Is this a known issue? 

Not that I've come across here.

 Why do I see these errors in catalina? 

As above.

 Should I somehow dispose off the connection pool myself?

Depends.


p

 Thank you for your time
 Best Regards,
 FH
 


-- 

[key:62590808]



signature.asc
Description: OpenPGP digital signature

Re: jdbc pool properties

2012-04-04 Thread Pid

On 04/04/2012 12:08, S Ahmed wrote:
 My db connections seem to be lost after an extended period of inactivity
 (for a web application).  And the only way to get the connections to work
 again is to restart tomcat.
 
 My tomcat.jdbc.pool.Datasource settings have:
 
  property name=maxActive value=100/
 property name=maxIdle value=30/
 property name=maxWait value=1000/
 property name=defaultAutoCommit value=true/
 property name=removeAbandoned value=true/
 property name=removeAbandonedTimeout value=60/
 
 
 Is it the removedAbonded and abandonedTimeout?  Does it mean after 60
 seconds, remove the connection from the pool?
 
 I guess what I need is a minActive setting then?

Do you have a connection validation query and test set?

E.g. testOnBorrow=true?


p


-- 

[key:62590808]



signature.asc
Description: OpenPGP digital signature

Re: jdbc pool properties

2012-04-04 Thread Daniel Mikusa

- Original Message -
My db connections seem to be lost after an extended period of
inactivity

There could be a number of reasons that this occurs. Perhaps a network issue
is causing them to be disconnected or the database may be timing them out. At
any rate, it's not likely that the problem would be caused by the
removeAbandoned / abandonedTimeout settings, unless you application is not
properly returning connections to the connection pool.

https://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html#Preventing_database_connection_pool_leaks

(for a web application). And the only way to get the connections to
work
again is to restart tomcat.

My tomcat.jdbc.pool.Datasource settings have:

property name=maxActive value=100/
property name=maxIdle value=30/
property name=maxWait value=1000/
property name=defaultAutoCommit value=true/
property name=removeAbandoned value=true/
property name=removeAbandonedTimeout value=60/

You probably want to add testOnBorrow=true and validationQuery=SELECT 1
(or some other valid query for your DB). See the following link for an
explanation of those properties.

https://commons.apache.org/dbcp/configuration.html

This will cause your connections to be validated prior to their use by your
application. Stale connections will be removed and replaced with new, working
connections.

Is it the removedAbonded and abandonedTimeout? Does it mean after
60
seconds, remove the connection from the pool?

No. See either of the links I've referenced above for an explanation of these
settings.

I guess what I need is a minActive setting then?

There's no minActive setting. You have minIdle, but I don't think that
would help here.

Dan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks

Hi Dan,

The following entry is in server.xml 

 Resource name=jdbc_GENERIS_RS auth=Container
  type=javax.sql.DataSource
  driverClassName=org.h2.Driver
  
url=jdbc:h2:file:/opt/en/repos/tomcat/webapps/GeneralApplication/db/internaldatabase;SCHEMA=genericschema
  username=root password=sa
  maxActive=20 maxIdle=10 maxWait=-1
  /


And the following entry is under $TOMCAT_HOME/conf/context.xml

 ResourceLink name=jdbc/GenericDataSource
    global=jdbc_GENERIS_RS
    type=javax.sql.DataSource/


Do you need more details than these?





 From: Daniel Mikusa dmik...@vmware.com
To: Tomcat Users List users@tomcat.apache.org 
Sent: Wednesday, April 4, 2012 3:35 PM
Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report 
on memory leaks
 


- Original Message -
 Hi,
 
 I am using Tomcat 7.0.25 in a Linux machine
 
 I am using Tomcat's connection pool
 (org.apache.tomcat.dbcp.dbcp.BasicDataSource). As database I am
 using H2 as a file database.

Where are you defining the connection pool?  Can you include your configuration?

Dan


 All is ok, but I have the following problem.
 On shutdown of Tomcat I see in catalina.out:
 
 
 SEVERE: The web application [/GeneralApplication] appears to have
 started a thread named [H2 Log Writer GENERICAPPLICATION] but has
 failed to stop it. This is very likely to create a memory leak.
 Apr 4, 2012 2:32:54 PM org.apache.catalina.loader.WebappClassLoader
 clearReferencesThreads
 SEVERE: The web application [/GeneralApplication] appears to have
 started a thread named [H2 File Lock Watchdog
 /opt/en/repos/tomcat/webapps/GeneralApplication/db/internaldatabase.lock.db]
 but has failed to stop it. This is very likely to create a memory
 leak.
 
 Why do I get these messages?
 As I understand these messages, H2 is still running on shutdown and
 the documentation they have says that the database will shutdown
 once the last connection is closed (and the connections are handled
 by the pool i.e. Tomcat)
 
 Additionally the input from H2 dev is that these messages are a
 Tomcat problem. Tomcat should have first disposed of the connection
 pool and then log the running threads.Their explanation seem correct
 to me.
 
 Is this a known issue? Why do I see these errors in catalina? Should
 I somehow dispose off the connection pool myself?
 
 Thank you for your time
 Best Regards,
 FH
 

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks

Hi Pid,

This is the configuration
The following entry is in server.xml 

 Resource name=jdbc_GENERIS_RS auth=Container
  type=javax.sql.DataSource
  driverClassName=org.h2.Driver
  
url=jdbc:h2:file:/opt/en/repos/tomcat/webapps/GeneralApplication/db/internaldatabase;SCHEMA=genericschema
  username=root password=sa
  maxActive=20 maxIdle=10 maxWait=-1
  /


And the following entry is under $TOMCAT_HOME/conf/context.xml

 ResourceLink name=jdbc/GenericDataSource
    global=jdbc_GENERIS_RS
    type=javax.sql.DataSource/

Concerning your other questions:
1) Yes I could shut down the database manually but I would like to do it as a 
last resort if this issue is something that can not be fixed since I believe 
that my setup is correct and should be supported as is

2) You say that it depends if I should close down the connection myself. But 
how can I do that? A javax.sql.DataSource does not provide a close method. I 
would have to cast to org.apache.tomcat.dbcp.dbcp.BasicDataSource to call 
close. I am not sure if this is the proper approach. I mean I then get bind to 
this class, right? Or there is another way?

Thank you




 From: Pid p...@pidster.com
To: Tomcat Users List users@tomcat.apache.org 
Sent: Wednesday, April 4, 2012 3:43 PM
Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report 
on memory leaks
 
On 04/04/2012 13:05, Hermes Flying wrote:
 Hi,
 
 I am using Tomcat 7.0.25 in a Linux machine
 
 I am using Tomcat's connection pool 
 (org.apache.tomcat.dbcp.dbcp.BasicDataSource). As database I am using H2 as a 
 file database.
 All is ok, but I have the following problem.
 On shutdown of Tomcat I see in catalina.out: 

In which file have you defined the pool?


 SEVERE: The web application [/GeneralApplication] appears to have started a 
 thread named [H2 Log Writer GENERICAPPLICATION] but has failed to stop it. 
 This is very likely to create a memory leak.
 Apr 4, 2012 2:32:54 PM org.apache.catalina.loader.WebappClassLoader 
 clearReferencesThreads
 SEVERE: The web application [/GeneralApplication] appears to have started a 
 thread named [H2 File Lock Watchdog 
 /opt/en/repos/tomcat/webapps/GeneralApplication/db/internaldatabase.lock.db] 
 but has failed to stop it. This is very likely to create a memory leak.
 
 Why do I get these messages?

When the application shuts down Tomcat tries to detect  prevent memory
leaks by examining threads  various things associated with the
WebappClassloader.


 As I understand these messages, H2 is still running on shutdown and the 
 documentation they have says that the database will shutdown once the last 
 connection is closed (and the connections are handled by the pool i.e. Tomcat)

So there is no way to manually the database down?


 Additionally the input from H2 dev is that these messages are a Tomcat 
 problem. Tomcat should have first disposed of the connection pool and then 
 log the running threads.Their explanation seem correct to me.

That's the usual first response.  Let's figure out whether it's correct...


 Is this a known issue? 

Not that I've come across here.

 Why do I see these errors in catalina? 

As above.

 Should I somehow dispose off the connection pool myself?

Depends.


p

 Thank you for your time
 Best Regards,
 FH
 


-- 

[key:62590808]

Tomcat6 thread pool questions

2012-04-04 Thread llowder


Greetings,

I was wondering if someone could help me understand how the threadpools are
handled in tomcat6. I know that a lot of the functionality was moved to
executors.

I set one up and using psi-Probe I could see that it was indeed killing off
threads as I expected. However, the minSpareThreads did not seem to be used
at all.

Is my understanding of that attribute correct, in that minSparethreads
should be the minimum number of threads running at any point?

For example, if I have minSpareThreads set to 30, I should see 30 threads
when the server is idle, and between 30 and maxThreads when it is under a
load, right?

That is not what I am seeing, as most of the time there are only 2-3
threads with one busy thread while the server is idle or near idle.

If anyone could let me know either what I am missing or what it is I do not
understand correctly, I would appreciate it.

Thank you.

Lee Lowder

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: jdbc pool properties

2012-04-04 Thread Propes, Barry L

There are some databases that do go in and periodically kill off connections, 
aside from the Tomcat settings.

In addition to testOnBorrow=true, I also had two other attributes, but not sure 
if Tomcat 7.0 uses them or not, as I'm on 6.0.29.

testOnBorrow=true
timeBetweenEvictionRunsMillis=-1
minEvictableIdleTimeMillis=28800



-Original Message-
From: Daniel Mikusa [mailto:dmik...@vmware.com]
Sent: Wednesday, April 04, 2012 7:46 AM
To: Tomcat Users List
Subject: Re: jdbc pool properties



- Original Message -
 My db connections seem to be lost after an extended period of
 inactivity

There could be a number of reasons that this occurs.  Perhaps a network issue 
is causing them to be disconnected or the database may be timing them out.  At 
any rate, it's not likely that the problem would be caused by the 
removeAbandoned / abandonedTimeout settings, unless you application is not 
properly returning connections to the connection pool.

  
https://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html#Preventing_database_connection_pool_leaks


 (for a web application).  And the only way to get the connections to
 work again is to restart tomcat.

 My tomcat.jdbc.pool.Datasource settings have:

  property name=maxActive value=100/
 property name=maxIdle value=30/
 property name=maxWait value=1000/
 property name=defaultAutoCommit value=true/
 property name=removeAbandoned value=true/
 property name=removeAbandonedTimeout value=60/


You probably want to add testOnBorrow=true and validationQuery=SELECT 1  
(or some other valid query for your DB).  See the following link for an 
explanation of those properties.

  https://commons.apache.org/dbcp/configuration.html

This will cause your connections to be validated prior to their use by your 
application.  Stale connections will be removed and replaced with new, working 
connections.


 Is it the removedAbonded and abandonedTimeout?  Does it mean after 60
 seconds, remove the connection from the pool?

No.  See either of the links I've referenced above for an explanation of these 
settings.


 I guess what I need is a minActive setting then?


There's no minActive setting.  You have minIdle, but I don't think that 
would help here.

Dan





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat6 - Context - aliases

2012-04-04 Thread Léa Massiot

Hello André,


André Warnier wrote
 
 - you need to tell your webapp where the uploaded files should be
 stored/retrieved
 - you cannot do it via an alias under Tomcat  v7 
 

Exactly.


André Warnier wrote
 
 - so instead of an alias, do it via a property in a properties file, which
 your webapp would read. This is (almost) a pure java solution, which
 would work under any servlet container of any version.
 

I wish I knew how to do that and yes, I'm interested in an (almost) pure
Java solution.



May I precise what I did and what already works with Tomcat7:

1) When a user uploads a file to the server running Tomcat, I store the
file, for example, in a directory: /home/d1/

2) In a JSP, this user can view the list of the n files he uploaded:
--
 a href=/an_alias_1/file_1.txt file_1.txt  /a
...
 a href=/an_alias_1/file_n.txt file_n.txt  /a
--

3) In Tomcat7, I used the aliases properties of the Context element in
META-INF/context.xml to (magically to me :/), let Tomcat map these
addresses:
--
/an_alias_1/file_1.txt
...
/an_alias_1/file_n.txt
--
to their real addresses on the  filesystem:
--
/home/d1/file_1.txt 
...
/home/d1/file_n.txt 
--
so that the user could click on one of these links and retrieve/view the
corresponding resource.

Of course, I read carefully what you wrote, it looks like I'm really missing
something important because I have absolutely no idea how to implement the
same mechanism using a properties file as you suggest...
Would you be so very kind to to explain a bit more?

Thank you and best regards.

--
View this message in context: 
http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4686704.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

SEVERE: Unable to start cluster.

2012-04-04 Thread Dhaval Jaiswal

Hi List,

Below is the error we are facing while starting tomcats.

SEVERE: Unable to start cluster.
org.apache.catalina.tribes.ChannelException: java.net.SocketException: Not
a multicast address; No faulty members identified.


Our cluster setting is as below in server.xml


 Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
channelSendOptions=6
Manager className=org.apache.catalina.ha.session.BackupManager
expireSessionsOnShutdown=false
   notifyListenersOnReplication=true mapSendOptions=6/

Channel
className=org.apache.catalina.tribes.group.GroupChannel
 Membership
className=org.apache.catalina.tribes.membership.McastService
address=192.168.3.14
port=45564
frequency=500
dropTime=3/
 Receiver
className=org.apache.catalina.tribes.transport.nio.NioReceiver
  address=auto
  port=4000
  selectorTimeout=5000
  timeout=6
  maxThreads=6/

 Sender
className=org.apache.catalina.tribes.transport.ReplicationTransmitter
  Transport
className=org.apache.catalina.tribes.transport.nio.PooledParallelSender
timeout=6 keepAliveCount=0/
 /Sender
 Interceptor
className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector/
 Interceptor
className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor/
 Interceptor
className=org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor/
   /Channel
 Valve className=org.apache.catalina.ha.tcp.ReplicationValve

filter=.*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt/
 Valve
className=org.apache.catalina.ha.session.JvmRouteBinderValve/
   ClusterListener
className=org.apache.catalina.ha.session.ClusterSessionListener/
   ClusterListener
className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/
 /Cluster



Note: 192.168.3.14 is the IP of backup manager with java  192.168.3.9 is
the IP address of local tomcat where above server.xml is hosted.

Please guide us as to how to overcome the issue  please give us the sample
cluster   /cluster  file if possible.

AW: AW: FormAuthentication Valve changes fail with RequestListeners?

2012-04-04 Thread Thomas Strauß

 -Ursprüngliche Nachricht-
 Von: André Warnier [mailto:a...@ice-sa.com]
 Gesendet: Dienstag, 3. April 2012 14:07
 An: Tomcat Users List
 Betreff: Re: AW: FormAuthentication Valve changes fail with
 RequestListeners?

 Thomas Strauß wrote:
 ...

 
  We have not succeeded so far. I want to give you some more
  information what happens, the context.xml and the web.xml
 
  What we have changed versus the existing setup, working on 7.0.11
  - We have moved the login.jsp into the protection domain (was
  outside before). This did not remove the issue.
  - We have changed the preemptiveAuthentication setting. This did not
  remove the issue.
 
  This is the flow through the system that we can see:
 
  Client sends request to /portal
 
 /portal is not protected
 /portal/jsp/main.jsp is welcome page and protected (see
  web.xml)
 portal context configures formauthentication on the
  protection domain
 Tomcat redirects/forwards incoming call to /jsp/login.jsp
  (protected
  resource)
 

 I have not followed in the details, and maybe I am talking out of turn
 here, but isn't there a loop problem if the login.jsp page is itself
 protected ?
 (Like it will trigger the authentication, which will trigger a redirect to
 login.jsp, which will trigger the authentication, which will... etc.)


there is no difference if the jsp is in or out of the protection domain. 
Actually we moved the jsp inside the domain following a hint from the list :-)



 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org


 --
 This message has been scanned for viruses and dangerous content by
 MailScanner, and is believed to be clean.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: FormAuthentication Valve changes fail with RequestListeners?

2012-04-04 Thread Thomas Strauß

Repeating the message because I signed it (again, *sigh*), causing trouble - 
sorry.

Hi,

we have done the tests and got the following results (7.0.11 and 7.0.26).

Thank you for taking the time:

=== Tomcat 7.0.11
==
First call to portal:

[http-bio-8080-exec-3| INFO  | 30-03 16:47:29:005]  
requestInitialized
[de.srs.pen.portal.utils.server.servlet.PortalRequestListener.requestInitial
ized(PortalRequestListener.java:52)]
[http-bio-8080-exec-3| INFO  | 30-03 16:47:29:005]
PortalRequest thread: 39 - http-bio-8080-exec-3
[de.srs.pen.portal.utils.server.servlet.PortalRequest.set(PortalRequest.java
:45)]
[http-bio-8080-exec-3| TRACE | 30-03 16:47:30:186]
Request Listener: Request Initialized
[de.srs.pen.portal.utils.server.servlet.PortalRequestListener.requestInitial
ized(PortalRequestListener.java:60)]
[http-bio-8080-exec-3| TRACE | 30-03 16:47:30:187]
requested URI:/portal-srs-standard/
[de.srs.pen.portal.utils.server.servlet.PortalRequestListener.requestInitial
ized(PortalRequestListener.java:62)]
[http-bio-8080-exec-3| TRACE | 30-03 16:47:30:187]
httpSession ID: 2D7D25B19BDC1A64DFFD61BBFD93CE7F
[de.srs.pen.portal.utils.server.servlet.PortalRequestListener.requestInitial
ized(PortalRequestListener.java:63)]
[http-bio-8080-exec-3| TRACE | 30-03 16:47:30:187]
principal:no principal
[de.srs.pen.portal.utils.server.servlet.PortalRequestListener.requestInitial
ized(PortalRequestListener.java:66)]
[http-bio-8080-exec-3| TRACE | 30-03 16:47:30:187]  stack
trace:
[de.srs.pen.portal.utils.server.servlet.PortalRequestListener.requestInitial
ized(PortalRequestListener.java:67)]
java.lang.Exception
at
de.srs.pen.portal.utils.server.servlet.PortalRequestListener.requestInitiali
zed(PortalRequestListener.java:67)
at
org.apache.catalina.core.StandardContext.fireRequestInitEvent(StandardContex
t.java:5903)
at
org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormA
uthenticator.java:372)
at
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthent
icator.java:267)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase
.java:556)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:562)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164
)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100
)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:562)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:394)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:243)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http
11Protocol.java:188)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:
302)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
va:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
08)
at java.lang.Thread.run(Thread.java:662)


Credentials provided, login done

[http-bio-8080-exec-3| TRACE | 30-03 16:47:47:246]
Request Listener: Request Initialized
[de.srs.pen.portal.utils.server.servlet.PortalRequestListener.requestInitial
ized(PortalRequestListener.java:60)]
[http-bio-8080-exec-3| TRACE | 30-03 16:47:50:803]
requested URI:/portal-srs-standard/
[de.srs.pen.portal.utils.server.servlet.PortalRequestListener.requestInitial
ized(PortalRequestListener.java:62)]
[http-bio-8080-exec-3| TRACE | 30-03 16:47:50:803]
httpSession ID: 17E5174AC9E99DC97A44B0967E3E0219
[de.srs.pen.portal.utils.server.servlet.PortalRequestListener.requestInitial
ized(PortalRequestListener.java:63)]
[http-bio-8080-exec-3| TRACE | 30-03 16:47:50:804]
principal:srs/m.strauss
[de.srs.pen.portal.utils.server.servlet.PortalRequestListener.requestInitial
ized(PortalRequestListener.java:66)]
[http-bio-8080-exec-3| TRACE | 30-03 16:47:50:804]  stack
trace:
[de.srs.pen.portal.utils.server.servlet.PortalRequestListener.requestInitial
ized(PortalRequestListener.java:67)]
java.lang.Exception
at
de.srs.pen.portal.utils.server.servlet.PortalRequestListener.requestInitiali
zed(PortalRequestListener.java:67)
at
org.apache.catalina.core.StandardContext.fireRequestInitEvent(StandardContex
t.java:5903)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:160)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase
.java:591)
at

Re: SEVERE: Unable to start cluster.

2012-04-04 Thread Daniel Mikusa

- Original Message -
 Hi List,
 
 Below is the error we are facing while starting tomcats.
 
 SEVERE: Unable to start cluster.
 org.apache.catalina.tribes.ChannelException:
 java.net.SocketException: Not
 a multicast address; No faulty members identified.
 

The address you specified is not a multicast address.  See the following link 
for info on multicast addresses.

  https://en.wikipedia.org/wiki/Multicast_address

 
 Our cluster setting is as below in server.xml
 
 
  Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
 channelSendOptions=6
 Manager
 className=org.apache.catalina.ha.session.BackupManager
 expireSessionsOnShutdown=false
notifyListenersOnReplication=true
mapSendOptions=6/
 
 Channel
 className=org.apache.catalina.tribes.group.GroupChannel
  Membership
 className=org.apache.catalina.tribes.membership.McastService

 address=192.168.3.14

This is the address which is referenced from the error above.  It's not a 
multicast address.

 port=45564
 frequency=500
 dropTime=3/
  Receiver
 className=org.apache.catalina.tribes.transport.nio.NioReceiver
   address=auto
   port=4000
   selectorTimeout=5000
   timeout=6
   maxThreads=6/
 
  Sender
 className=org.apache.catalina.tribes.transport.ReplicationTransmitter
   Transport
 className=org.apache.catalina.tribes.transport.nio.PooledParallelSender
 timeout=6 keepAliveCount=0/
  /Sender
  Interceptor
 className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector/
  Interceptor
 className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor/
  Interceptor
 className=org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor/
/Channel
  Valve
  className=org.apache.catalina.ha.tcp.ReplicationValve
 
 filter=.*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt/
  Valve
 className=org.apache.catalina.ha.session.JvmRouteBinderValve/
ClusterListener
 className=org.apache.catalina.ha.session.ClusterSessionListener/
ClusterListener
 className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/
  /Cluster
 
 
 
 Note: 192.168.3.14 is the IP of backup manager with java 
 192.168.3.9 is
 the IP address of local tomcat where above server.xml is hosted.
 
 Please guide us as to how to overcome the issue 

Use a correct multicast address.

 please give us the sample

See the section title For the impatient.

  https://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html

Dan


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: SEVERE: Unable to start cluster.

2012-04-04 Thread Thomas Rohde

-Ursprüngliche Nachricht-
Von:Dhaval Jaiswal dhaval.jais...@via.com
Gesendet:   Mi 04.04.2012 16:41
Betreff:SEVERE: Unable to start cluster.
An: Tomcat Users List users@tomcat.apache.org; 
CC: Shrinivas Devarkonda shrinivas.devarko...@via.com; 
 Hi List,
 
 Below is the error we are facing while starting tomcats.
 
 SEVERE: Unable to start cluster.
 org.apache.catalina.tribes.ChannelException: java.net.SocketException: Not
 a multicast address; No faulty members identified.
 
 
 Our cluster setting is as below in server.xml
 
 
  Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
 channelSendOptions=6
 Manager className=org.apache.catalina.ha.session.BackupManager
 expireSessionsOnShutdown=false
notifyListenersOnReplication=true mapSendOptions=6/
 
 Channel
 className=org.apache.catalina.tribes.group.GroupChannel
  Membership
 className=org.apache.catalina.tribes.membership.McastService
 address=192.168.3.14
 port=45564
 frequency=500
 dropTime=3/
  Receiver
 className=org.apache.catalina.tribes.transport.nio.NioReceiver
   address=auto
   port=4000
   selectorTimeout=5000
   timeout=6
   maxThreads=6/
 
  Sender
 className=org.apache.catalina.tribes.transport.ReplicationTransmitter
   Transport
 className=org.apache.catalina.tribes.transport.nio.PooledParallelSender
 timeout=6 keepAliveCount=0/
  /Sender
  Interceptor
 className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector/
  Interceptor
 className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interc
 eptor/
  Interceptor
 className=org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor/
 
/Channel
  Valve className=org.apache.catalina.ha.tcp.ReplicationValve
 
 filter=.*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt
 /
  Valve
 className=org.apache.catalina.ha.session.JvmRouteBinderValve/
ClusterListener
 className=org.apache.catalina.ha.session.ClusterSessionListener/
ClusterListener
 className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/
  /Cluster
 
 
 
 Note: 192.168.3.14 is the IP of backup manager with java  192.168.3.9 is
 the IP address of local tomcat where above server.xml is hosted.
 
 Please guide us as to how to overcome the issue  please give us the sample
 cluster   /cluster  file if possible.
 

Hi Dhaval,

you have to set a multicast ip address for the address attribute of the 
McastService. A multicast address looks like 224.x.x.x.

Take a look at http://en.wikipedia.org/wiki/Multicast_address for further 
details.

The Tomcat cluster uses multicast for the management of the cluster member.

Thomas

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat6 thread pool questions

On 04/04/2012 14:50, llow...@oreillyauto.com wrote:
 
 Greetings,
 
 I was wondering if someone could help me understand how the threadpools are
 handled in tomcat6. I know that a lot of the functionality was moved to
 executors.
 
 I set one up and using psi-Probe I could see that it was indeed killing off
 threads as I expected. However, the minSpareThreads did not seem to be used
 at all.

And where do you see minSpareThreads defined as a valid attribute for a
Connector element in the Tomcat 6 documentation?

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks

On 04/04/2012 13:54, Hermes Flying wrote:
 Hi Pid,
 
 This is the configuration The following entry is in server.xml
 
 Resource name=jdbc_GENERIS_RS auth=Container 
 type=javax.sql.DataSource driverClassName=org.h2.Driver 
 url=jdbc:h2:file:/opt/en/repos/tomcat/webapps/GeneralApplication/db/internaldatabase;SCHEMA=genericschema

 
username=root password=sa
 maxActive=20 maxIdle=10 maxWait=-1 /

OK. That means it is a server wide connection pool...

 And the following entry is under $TOMCAT_HOME/conf/context.xml
 
 ResourceLink name=jdbc/GenericDataSource global=jdbc_GENERIS_RS 
 type=javax.sql.DataSource/

... that is shared by one or more applications.

 Concerning your other questions: 1) Yes I could shut down the
 database manually but I would like to do it as a last resort if this
 issue is something that can not be fixed since I believe that my
 setup is correct and should be supported as is

Based on what I have seen so far, I would agree.

 2) You say that it depends if I should close down the connection
 myself. But how can I do that? A javax.sql.DataSource does not
 provide a close method. I would have to cast to
 org.apache.tomcat.dbcp.dbcp.BasicDataSource to call close. I am not
 sure if this is the proper approach. I mean I then get bind to this
 class, right? Or there is another way?

Not that is applies in this case (since the pool is global rather than
per application) but as of 7.0.12 yo an set the closeMethod for a
resource that should be the name of a zero atg method to call to shut
down the resource

 SEVERE: The web application [/GeneralApplication] appears to have
 started a thread named [H2 Log Writer GENERICAPPLICATION] but has
 failed to stop it. This is very likely to create a memory leak. Apr
 4, 2012 2:32:54 PM org.apache.catalina.loader.WebappClassLoader
 clearReferencesThreads


SEVERE: The web application
 [/GeneralApplication] appears to have started a thread named [H2
 File Lock Watchdog
 /opt/en/repos/tomcat/webapps/GeneralApplication/db/internaldatabase.lock.db]
 but has failed to stop it. This is very likely to create a memory
 leak.
 
 Why do I get these messages?

What is happening is the the JDBC driver is creating threads. When a
thread is created the context class loader for the thread is - by
default - set to the current context class loader. These threads are
being created when the current context class loader is the web
application class loader. i.e. they are being created as a result of the
web application using the JDBC driver (via the pool). When the web
application stops those threads are still in use (since it is a global
pool) but the threads retain a reference to the web application class
loader and this creates a memory leak.

 Additionally the input from H2 dev is that these messages are a
 Tomcat problem. Tomcat should have first disposed of the connection
 pool and then log the running threads.Their explanation seem
 correct to me.
 
 That's the usual first response.  Let's figure out whether it's
 correct...

And it is wrong. When H2 creates those threads it should ensure that the
context class loader for the threads is set to the same class loader
that loaded the JDBC driver. We had similar issues with the evictor
thread in Apache Commons Pool (used by DBCP).

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks

Which is indicating that the application deployed to /GeneralApplication is 
creating a thread named H2 Log Writer GENERICAPPLICATION and never 
stopping it.  I do not believe that this would be associated with the pool 
created by Tomcat as that would be created as a global resource available 
to all applications and not specific to /GeneralApplication.
I can't really say a whole lot more about what is going on, just that this 
strikes me as odd.  If it were my app, I'd dig into this more and see what is 
creating that thread.  Possibly with a profiler or thread dumps.

What is happening here (as I undestand it is the following):
1) My application uses Tomcat's connection pool from the data source
2) My application uses H2 as a file database. H2 starts back end(s) thread 
which is about logging (H2 logging) and possibly other tasks and that is the 
thread that catalina complaints about
3) H2 remains open as long as there are open connections and is closed when the 
last connection is released
4) My application uses Tomcat's connection pool and as a result Tomcat 
decides when the data source should be disposed or when connections are 
released (not my code).
5) I shutdown Tomcat. 
6) The connection pool of Tomcat has still connections (e.g. idle) and so H2 
does not shutdown. Hence it's lock file and related background threads are 
still running.
7) Tomcat shuts down my application but does not dispose off the connection 
pool (yet). I believe this happens because of the way Tomcat is being shut down 
(as sequence of actions I mean).
8) Since the connection pool has not been disposed, there are still connections 
and as a result H2 is still running
9) Tomcat's memory leak detection mechanism detects H2 threads started from 
GenericApplication which uses H2 and gives the report in catalina.out. So 
Tomcat gives the report first and then proceeds with the shutdown (and this 
perhaps is not correct? I can't say)
10) Tomcat eventually shuts down.
 
Is this scenario as I describe it, wrong?
Should I somehow have configured the datasource to be associated with my web 
application instead of a generic data source? Why? 
Should I have shut the data source myself? How?
If all what I describe is reasonable this seems to me like a racing 
condition. How should I mediate this?

Thank you for your time.
  


 From: Daniel Mikusa dmik...@vmware.com
To: Hermes Flying flyingher...@yahoo.com 
Sent: Wednesday, April 4, 2012 5:14 PM
Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report 
on memory leaks
  
- Original Message -
 
 
 What I do is get the dataSource inside a ServletContextListener and
 save it in servlet context (as part of a DAO Factory):
 
 public void contextInitialized(ServletContextEvent sce) {
 
 ServletContext context = sce.getServletContext();
 DataSource dataSource = null;
 try {
 dataSource = (DataSource) new
 InitialContext().lookup(java:/comp/env/jdbc/GenericDataSource);
 context.setAttribute(daogenericfactory,
 DAOGenericFactory.getInstance(dataSource));
 
 } catch (NamingException e) {
 e.printStackTrace();
 }
 
 }
 
 
 The DAOGenericFactory just returns specific DAO objects passing in
 their constructor the data source.
 Each DAO instance has an member variable of DataSource and for action
 to the database I do in order to get a connection:
 
 public Connection getConnection() throws Exception{
 return dataSource.getConnection();
 }
 
 
 So I use the Connection this way and I always close the connections
 in order to be returned back to the pool.
 The only thing perhaps to mention is that I create new DAO objects
 passing this data source (I don't reuse instances of DAO).
 So I don't have a pool of my own. I just use DAO pattern .
 This is happening in my web application GeneralApplication
 Is this information adequate/clear?

Definitely clear.  It just doesn't seem to match up with the output from the 
log files.  You're seeing

    SEVERE: The web application [/GeneralApplication] appears to have
    started a thread named [H2 Log Writer GENERICAPPLICATION] but has
    failed to stop it. This is very likely to create a memory leak.

Which is indicating that the application deployed to /GeneralApplication is 
creating a thread named H2 Log Writer GENERICAPPLICATION and never stopping 
it.  I do not believe that this would be associated with the pool created by 
Tomcat as that would be created as a global resource available to all 
applications and not specific to /GeneralApplication.

I can't really say a whole lot more about what is going on, just that this 
strikes me as odd.  If it were my app, I'd dig into this more and see what is 
creating that thread.  Possibly with a profiler or thread dumps.


 Also how did you test it? 

I took a stock Tomcat 7 instance, added the Resource/ tag you specified to 
server.xml and added the ResourceLink/ tag you specified to context.xml.  I 
then deployed a test app that I have, it's a simple

Re: jdbc pool properties

There are some databases that do go in and periodically kill off
connections, aside from the Tomcat settings.

you may want to explore the maxAge option for this, as we can disconnect and
create new connections before the DB does kills it as long lived

- Original Message -
From: Barry L Propes barry.l.pro...@citi.com
To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, April 4, 2012 7:53:26 AM
Subject: RE: jdbc pool properties

There are some databases that do go in and periodically kill off
connections, aside from the Tomcat settings.

In addition to testOnBorrow=true, I also had two other attributes,
but not sure if Tomcat 7.0 uses them or not, as I'm on 6.0.29.

testOnBorrow=true
timeBetweenEvictionRunsMillis=-1
minEvictableIdleTimeMillis=28800

-Original Message-
From: Daniel Mikusa [mailto:dmik...@vmware.com]
Sent: Wednesday, April 04, 2012 7:46 AM
To: Tomcat Users List
Subject: Re: jdbc pool properties

- Original Message -
My db connections seem to be lost after an extended period of
inactivity

There could be a number of reasons that this occurs. Perhaps a
network issue is causing them to be disconnected or the database may
be timing them out. At any rate, it's not likely that the problem
would be caused by the removeAbandoned / abandonedTimeout
settings, unless you application is not properly returning
connections to the connection pool.

https://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html#Preventing_database_connection_pool_leaks

(for a web application). And the only way to get the connections
to
work again is to restart tomcat.

My tomcat.jdbc.pool.Datasource settings have:

You probably want to add testOnBorrow=true and
validationQuery=SELECT 1 (or some other valid query for your DB).
See the following link for an explanation of those properties.

https://commons.apache.org/dbcp/configuration.html

This will cause your connections to be validated prior to their use
by your application. Stale connections will be removed and replaced
with new, working connections.

Is it the removedAbonded and abandonedTimeout? Does it mean after
60
seconds, remove the connection from the pool?

No. See either of the links I've referenced above for an explanation
of these settings.

I guess what I need is a minActive setting then?

There's no minActive setting. You have minIdle, but I don't
think that would help here.

Dan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [JDBC Pool] PoolCleaner creates some sort of memory

I'll take a look at the test failures, but yes you can ignore them. Tomcat 
7.0.27 will have the fix included, about to be released shortly
building it is easy, builds with both maven and ant

Filip

- Original Message -
 From: Michael Osipov michael.osi...@siemens.com
 To: Tomcat Users List users@tomcat.apache.org
 Sent: Friday, March 30, 2012 2:05:50 AM
 Subject: RE: [JDBC Pool] PoolCleaner creates some sort of memory

 Konstantin Kolinko wrote:
  2012/3/30 Osipov, Michael michael.osi...@siemens.com:
  Filip Hanik (mailing lists) wrote:
  http://svn.apache.org/viewvc?view=revisionrevision=1306946

  Thanks for the patch, I am having trouble to build from source. I
  do
  have some test failures, should I ignore them and go on?

  Please be more specific. In what tests?

 Have a look at this: http://pastebin.com/kiHLF6D9
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Bug in Tomcat AJP Connector?

2012-04-04 Thread Ofer Israeli

Hi all,

We have recently witnessed a strange situation.  Our Tomcat (6.0.35) listens on 
2 ports: 8080 and 8009, handling HTTP and AJP respectively.  At some point in 
time we found that Apache is replying HTTP 503s to all clients and a look at 
netstat showed that indeed Apache could not communicate with Tomcat - there 
were many connections in state SYN_SENT, that were never replied.  A test of 
attempting to connect to Tomcat's 8009 port turned out to give the same result, 
so the issue was obviously in Tomcat and not Apache.  But netstat also showed 
that Tomcat was listening on port 8009.  After digging into the logs, we found 
that there was an Out of Memory exception in the JK's accept() sequence and 
once this exception was caught there was a message of terminating thread.

So although the exception is caught and handled by killing the thread (isn't 
that a little drastic?), the socket isn't closed beforehand and thus the OS 
thinks that the port is still fine (in LISTENING state), as although the thread 
is dead, the process is alive.  Has anyone encountered this or knows if this 
bug is known?


Thanks,
Ofer

Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks

Hi Mark,thank you for your reply.
2 questions related your mail
1)I don't understand what you are saying here: but as of 7.0.12 yo an set the 
closeMethod for a resource that should be the name of a zero atg method to call 
to shut down the resource. Could you please explain or send a link to a 
reference on what you are talking about here?
2)Concerning your comment concerning the class loaders and H2. I didn't mention 
that the H2 driver is under $TOMCAT_HOME/lib. Does this make a difference in 
the behavior you describe? I mean the JDBC driver would not be unloaded with 
the web application, right? So is this an issue? Should I have placed the H2 
driver under WEB-INF/lib? 
I can do that but then from my point of view Tomcat's setup has many 
exception/corner cases and the setup is not uniform but requires some 
background knowledge of the implementation of Tomcat
 
Also as mentioned to Dan:
 
My undestanding of what is happening here is the following
1) My application uses Tomcat's connection pool from the data source
2) My application uses H2 as a file database. H2 starts back end(s) thread 
which is about logging (H2 logging) and possibly other tasks and that is the 
thread that catalina complaints about
3) H2 remains open as long as there are open connections and is closed when the 
last connection is released
4) My application uses Tomcat's connection pool and as a result Tomcat 
decides when the data source should be disposed or when connections are 
released (not my code).
5) I shutdown Tomcat. 
6) The connection pool of Tomcat has still connections (e.g. idle) and so H2 
does not shutdown. Hence it's lock file and related background threads are 
still running.
7) Tomcat shuts down my application but does not dispose off the connection 
pool (yet). I believe this happens because of the way Tomcat is being shut down 
(as sequence of actions I mean).
8) Since the connection pool has not been disposed, there are still connections 
and as a result H2 is still running
9) Tomcat's memory leak detection mechanism detects H2 threads started from 
GenericApplication which uses H2 and gives the report in catalina.out. So 
Tomcat gives the report first and then proceeds with the shutdown (and this 
perhaps is not correct? I can't say)
10) Tomcat eventually shuts down.

Is this scenario as I describe it, wrong?
Should I somehow have configured the datasource to be associated with my web 
application instead of a generic data source? Why? 
Should I have shut the data source myself? How?
If all what I describe is reasonable this seems to me like a racing 
condition. How should I mediate this?

Thank you for your time

 


 From: Mark Thomas ma...@apache.org
To: Tomcat Users List users@tomcat.apache.org 
Sent: Wednesday, April 4, 2012 6:42 PM
Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report 
on memory leaks
  
On 04/04/2012 13:54, Hermes Flying wrote:
 Hi Pid,
 
 This is the configuration The following entry is in server.xml
 
 Resource name=jdbc_GENERIS_RS auth=Container 
 type=javax.sql.DataSource driverClassName=org.h2.Driver 
 url=jdbc:h2:file:/opt/en/repos/tomcat/webapps/GeneralApplication/db/internaldatabase;SCHEMA=genericschema

 
username=root password=sa
 maxActive=20 maxIdle=10 maxWait=-1 /

OK. That means it is a server wide connection pool...

 And the following entry is under $TOMCAT_HOME/conf/context.xml
 
 ResourceLink name=jdbc/GenericDataSource global=jdbc_GENERIS_RS 
 type=javax.sql.DataSource/

... that is shared by one or more applications.

 Concerning your other questions: 1) Yes I could shut down the
 database manually but I would like to do it as a last resort if this
 issue is something that can not be fixed since I believe that my
 setup is correct and should be supported as is

Based on what I have seen so far, I would agree.

 2) You say that it depends if I should close down the connection
 myself. But how can I do that? A javax.sql.DataSource does not
 provide a close method. I would have to cast to
 org.apache.tomcat.dbcp.dbcp.BasicDataSource to call close. I am not
 sure if this is the proper approach. I mean I then get bind to this
 class, right? Or there is another way?

Not that is applies in this case (since the pool is global rather than
per application) but as of 7.0.12 yo an set the closeMethod for a
resource that should be the name of a zero atg method to call to shut
down the resource

 SEVERE: The web application [/GeneralApplication] appears to have
 started a thread named [H2 Log Writer GENERICAPPLICATION] but has
 failed to stop it. This is very likely to create a memory leak. Apr
 4, 2012 2:32:54 PM org.apache.catalina.loader.WebappClassLoader
 clearReferencesThreads


SEVERE: The web application
 [/GeneralApplication] appears to have started a thread named [H2
 File Lock Watchdog
 /opt/en/repos/tomcat/webapps/GeneralApplication/db/internaldatabase.lock.db]
 but has failed to stop it. This is very likely

Re: Tomcat6 thread pool questions

In Tomcat 6, the default thread pool ignores minSpareThreads, but if you use 
Executor name=threadpool... and then Connector executor=threadpool
it will respect that value and you will see the expected the results

Filip

- Original Message -
 From: llow...@oreillyauto.com
 To: users@tomcat.apache.org
 Sent: Wednesday, April 4, 2012 7:50:24 AM
 Subject: Tomcat6 thread pool questions

 Greetings,

 I was wondering if someone could help me understand how the
 threadpools are
 handled in tomcat6. I know that a lot of the functionality was moved
 to
 executors.

 I set one up and using psi-Probe I could see that it was indeed
 killing off
 threads as I expected. However, the minSpareThreads did not seem to
 be used
 at all.

 Is my understanding of that attribute correct, in that
 minSparethreads
 should be the minimum number of threads running at any point?

 For example, if I have minSpareThreads set to 30, I should see 30
 threads
 when the server is idle, and between 30 and maxThreads when it is
 under a
 load, right?

 That is not what I am seeing, as most of the time there are only 2-3
 threads with one busy thread while the server is idle or near idle.

 If anyone could let me know either what I am missing or what it is I
 do not
 understand correctly, I would appreciate it.

 Thank you.

 Lee Lowder

 This communication and any attachments are confidential, protected by
 Communications Privacy Act 18 USCS � 2510, solely for the use of the
 intended recipient, and may contain legally privileged material. If
 you are not the intended recipient, please return or destroy it
 immediately. Thank you.

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks

just set minIdle=0 and enable the eviction process to take care of it.

Filip

- Original Message -
 From: Hermes Flying flyingher...@yahoo.com
 To: Daniel Mikusa dmik...@vmware.com
 Cc: users@tomcat.apache.org
 Sent: Wednesday, April 4, 2012 9:53:30 AM
 Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report 
 on memory leaks

 Which is indicating that the application deployed to
 /GeneralApplication is creating a thread named H2 Log Writer
 GENERICAPPLICATION and never stopping it.  I do not believe
 that this would be associated with the pool created by Tomcat as
 that would be created as a global resource available to all
 applications and not specific to /GeneralApplication.
 I can't really say a whole lot more about what is going on, just
 that this strikes me as odd.  If it were my app, I'd dig into this
 more and see what is creating that thread.  Possibly with a
 profiler or thread dumps.

 What is happening here (as I undestand it is the following):
 1) My application uses Tomcat's connection pool from the data source
 2) My application uses H2 as a file database. H2 starts back end(s)
 thread which is about logging (H2 logging) and possibly other tasks
  and that is the thread that catalina complaints about
 3) H2 remains open as long as there are open connections and is
 closed when the last connection is released
 4) My application uses Tomcat's connection pool and as a result
 Tomcat decides when the data source should be disposed or when
 connections are released (not my code).
 5) I shutdown Tomcat.
 6) The connection pool of Tomcat has still connections (e.g. idle)
 and so H2 does not shutdown. Hence it's lock file and related
 background threads are still running.
 7) Tomcat shuts down my application but does not dispose off the
 connection pool (yet). I believe this happens because of the way
 Tomcat is being shut down (as sequence of actions I mean).
 8) Since the connection pool has not been disposed, there are still
 connections and as a result H2 is still running
 9) Tomcat's memory leak detection mechanism detects H2 threads
 started from GenericApplication which uses H2 and gives the report
 in catalina.out. So Tomcat gives the report first and then proceeds
 with the shutdown (and this perhaps is not correct? I can't say)
 10) Tomcat eventually shuts down.

 Is this scenario as I describe it, wrong?
 Should I somehow have configured the datasource to be associated
 with my web application instead of a generic data source? Why?
 Should I have shut the data source myself? How?
 If all what I describe is reasonable this seems to me like a racing
 condition. How should I mediate this?

 Thank you for your time.

  From: Daniel Mikusa dmik...@vmware.com
 To: Hermes Flying flyingher...@yahoo.com
 Sent: Wednesday, April 4, 2012 5:14 PM
 Subject: Re: Discrepancy between Tomcat's connection pool and
 tomcat's report on memory leaks

 - Original Message -

  What I do is get the dataSource inside a ServletContextListener and
  save it in servlet context (as part of a DAO Factory):

  public void contextInitialized(ServletContextEvent sce) {

  ServletContext context = sce.getServletContext();
  DataSource dataSource = null;
  try {
  dataSource = (DataSource) new
  InitialContext().lookup(java:/comp/env/jdbc/GenericDataSource);
  context.setAttribute(daogenericfactory,
  DAOGenericFactory.getInstance(dataSource));

  } catch (NamingException e) {
  e.printStackTrace();
  }

  }

  The DAOGenericFactory just returns specific DAO objects passing in
  their constructor the data source.
  Each DAO instance has an member variable of DataSource and for
  action
  to the database I do in order to get a connection:

  public Connection getConnection() throws Exception{
  return dataSource.getConnection();
  }

  So I use the Connection this way and I always close the connections
  in order to be returned back to the pool.
  The only thing perhaps to mention is that I create new DAO objects
  passing this data source (I don't reuse instances of DAO).
  So I don't have a pool of my own. I just use DAO pattern .
  This is happening in my web application GeneralApplication
  Is this information adequate/clear?

 Definitely clear.  It just doesn't seem to match up with the output
 from the log files.  You're seeing

     SEVERE: The web application [/GeneralApplication] appears to have
     started a thread named [H2 Log Writer GENERICAPPLICATION] but has
     failed to stop it. This is very likely to create a memory leak.

 Which is indicating that the application deployed to
 /GeneralApplication is creating a thread named H2 Log Writer
 GENERICAPPLICATION and never stopping it.  I do not believe that
 this would be associated with the pool created by Tomcat as that
 would be created as a global resource available to all applications
 and not specific to /GeneralApplication.

 I can't really say a whole lot

Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks

But if I set 'minIdle=0' all the connections would close imediatelly, right?
So why would I need a connection pool in the first place if I do this?

 From: Filip Hanik Mailing Lists devli...@hanik.com
To: Tomcat Users List users@tomcat.apache.org 
Sent: Wednesday, April 4, 2012 7:28 PM
Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report 
on memory leaks

just set minIdle=0 and enable the eviction process to take care of it.

Filip

- Original Message -
 From: Hermes Flying flyingher...@yahoo.com
 To: Daniel Mikusa dmik...@vmware.com
 Cc: users@tomcat.apache.org
 Sent: Wednesday, April 4, 2012 9:53:30 AM
 Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report 
 on memory leaks

 Which is indicating that the application deployed to
 /GeneralApplication is creating a thread named H2 Log Writer
 GENERICAPPLICATION and never stopping it.  I do not believe
 that this would be associated with the pool created by Tomcat as
 that would be created as a global resource available to all
 applications and not specific to /GeneralApplication.
 I can't really say a whole lot more about what is going on, just
 that this strikes me as odd.  If it were my app, I'd dig into this
 more and see what is creating that thread.  Possibly with a
 profiler or thread dumps.

 What is happening here (as I undestand it is the following):
 1) My application uses Tomcat's connection pool from the data source
 2) My application uses H2 as a file database. H2 starts back end(s)
 thread which is about logging (H2 logging) and possibly other tasks
  and that is the thread that catalina complaints about
 3) H2 remains open as long as there are open connections and is
 closed when the last connection is released
 4) My application uses Tomcat's connection pool and as a result
 Tomcat decides when the data source should be disposed or when
 connections are released (not my code).
 5) I shutdown Tomcat.
 6) The connection pool of Tomcat has still connections (e.g. idle)
 and so H2 does not shutdown. Hence it's lock file and related
 background threads are still running.
 7) Tomcat shuts down my application but does not dispose off the
 connection pool (yet). I believe this happens because of the way
 Tomcat is being shut down (as sequence of actions I mean).
 8) Since the connection pool has not been disposed, there are still
 connections and as a result H2 is still running
 9) Tomcat's memory leak detection mechanism detects H2 threads
 started from GenericApplication which uses H2 and gives the report
 in catalina.out. So Tomcat gives the report first and then proceeds
 with the shutdown (and this perhaps is not correct? I can't say)
 10) Tomcat eventually shuts down.

 Is this scenario as I describe it, wrong?
 Should I somehow have configured the datasource to be associated
 with my web application instead of a generic data source? Why?
 Should I have shut the data source myself? How?
 If all what I describe is reasonable this seems to me like a racing
 condition. How should I mediate this?

 Thank you for your time.

  From: Daniel Mikusa dmik...@vmware.com
 To: Hermes Flying flyingher...@yahoo.com
 Sent: Wednesday, April 4, 2012 5:14 PM
 Subject: Re: Discrepancy between Tomcat's connection pool and
 tomcat's report on memory leaks

 - Original Message -

  What I do is get the dataSource inside a ServletContextListener and
  save it in servlet context (as part of a DAO Factory):

  public void contextInitialized(ServletContextEvent sce) {

  ServletContext context = sce.getServletContext();
  DataSource dataSource = null;
  try {
  dataSource = (DataSource) new
  InitialContext().lookup(java:/comp/env/jdbc/GenericDataSource);
  context.setAttribute(daogenericfactory,
  DAOGenericFactory.getInstance(dataSource));

  } catch (NamingException e) {
  e.printStackTrace();
  }

  }

  The DAOGenericFactory just returns specific DAO objects passing in
  their constructor the data source.
  Each DAO instance has an member variable of DataSource and for
  action
  to the database I do in order to get a connection:

  public Connection getConnection() throws Exception{
  return dataSource.getConnection();
  }

  So I use the Connection this way and I always close the connections
  in order to be returned back to the pool.
  The only thing perhaps to mention is that I create new DAO objects
  passing this data source (I don't reuse instances of DAO).
  So I don't have a pool of my own. I just use DAO pattern .
  This is happening in my web application GeneralApplication
  Is this information adequate/clear?

 Definitely clear.  It just doesn't seem to match up with the output
 from the log files.  You're seeing

     SEVERE: The web application [/GeneralApplication] appears to have
     started a thread named [H2 Log Writer GENERICAPPLICATION] but has
     failed to stop it. This is very likely

Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks

no, that would happen if you set maxIdle=0, not minIdle

- Original Message -
 From: Hermes Flying flyingher...@yahoo.com
 To: Tomcat Users List users@tomcat.apache.org
 Sent: Wednesday, April 4, 2012 10:45:24 AM
 Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report 
 on memory leaks

 But if I set 'minIdle=0' all the connections would close imediatelly,
 right?
 So why would I need a connection pool in the first place if I do
 this?

  From: Filip Hanik Mailing Lists devli...@hanik.com
 To: Tomcat Users List users@tomcat.apache.org
 Sent: Wednesday, April 4, 2012 7:28 PM
 Subject: Re: Discrepancy between Tomcat's connection pool and
 tomcat's report on memory leaks

 just set minIdle=0 and enable the eviction process to take care of
 it.

 Filip

 - Original Message -
  From: Hermes Flying flyingher...@yahoo.com
  To: Daniel Mikusa dmik...@vmware.com
  Cc: users@tomcat.apache.org
  Sent: Wednesday, April 4, 2012 9:53:30 AM
  Subject: Re: Discrepancy between Tomcat's connection pool and
  tomcat's report on memory leaks

  Which is indicating that the application deployed to
  /GeneralApplication is creating a thread named H2 Log Writer
  GENERICAPPLICATION and never stopping it.  I do not believe
  that this would be associated with the pool created by Tomcat as
  that would be created as a global resource available to all
  applications and not specific to /GeneralApplication.
  I can't really say a whole lot more about what is going on, just
  that this strikes me as odd.  If it were my app, I'd dig into
  this
  more and see what is creating that thread.  Possibly with a
  profiler or thread dumps.

  What is happening here (as I undestand it is the following):
  1) My application uses Tomcat's connection pool from the data
  source
  2) My application uses H2 as a file database. H2 starts back end(s)
  thread which is about logging (H2 logging) and possibly other tasks
   and that is the thread that catalina complaints about
  3) H2 remains open as long as there are open connections and is
  closed when the last connection is released
  4) My application uses Tomcat's connection pool and as a result
  Tomcat decides when the data source should be disposed or when
  connections are released (not my code).
  5) I shutdown Tomcat.
  6) The connection pool of Tomcat has still connections (e.g. idle)
  and so H2 does not shutdown. Hence it's lock file and related
  background threads are still running.
  7) Tomcat shuts down my application but does not dispose off the
  connection pool (yet). I believe this happens because of the way
  Tomcat is being shut down (as sequence of actions I mean).
  8) Since the connection pool has not been disposed, there are still
  connections and as a result H2 is still running
  9) Tomcat's memory leak detection mechanism detects H2 threads
  started from GenericApplication which uses H2 and gives the report
  in catalina.out. So Tomcat gives the report first and then proceeds
  with the shutdown (and this perhaps is not correct? I can't say)
  10) Tomcat eventually shuts down.

  Is this scenario as I describe it, wrong?
  Should I somehow have configured the datasource to be associated
  with my web application instead of a generic data source? Why?
  Should I have shut the data source myself? How?
  If all what I describe is reasonable this seems to me like a
  racing
  condition. How should I mediate this?

  Thank you for your time.

   From: Daniel Mikusa dmik...@vmware.com
  To: Hermes Flying flyingher...@yahoo.com
  Sent: Wednesday, April 4, 2012 5:14 PM
  Subject: Re: Discrepancy between Tomcat's connection pool and
  tomcat's report on memory leaks

  - Original Message -

   What I do is get the dataSource inside a ServletContextListener
   and
   save it in servlet context (as part of a DAO Factory):

   public void contextInitialized(ServletContextEvent sce) {

   ServletContext context = sce.getServletContext();
   DataSource dataSource = null;
   try {
   dataSource = (DataSource) new
   InitialContext().lookup(java:/comp/env/jdbc/GenericDataSource);
   context.setAttribute(daogenericfactory,
   DAOGenericFactory.getInstance(dataSource));

   } catch (NamingException e) {
   e.printStackTrace();
   }

   }

   The DAOGenericFactory just returns specific DAO objects passing
   in
   their constructor the data source.
   Each DAO instance has an member variable of DataSource and for
   action
   to the database I do in order to get a connection:

   public Connection getConnection() throws Exception{
   return dataSource.getConnection();
   }

   So I use the Connection this way and I always close the
   connections
   in order to be returned back to the pool.
   The only thing perhaps to mention is that I create new DAO
   objects
   passing this data source (I don't reuse instances of DAO).
   So I

Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks

Ok. So how is the configuration parameter fixing my problem? Would you please 
explain this to me to undestand how this works?

 From: Filip Hanik Mailing Lists devli...@hanik.com
To: Tomcat Users List users@tomcat.apache.org; Hermes Flying 
flyingher...@yahoo.com 
Sent: Wednesday, April 4, 2012 7:50 PM
Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report 
on memory leaks

no, that would happen if you set maxIdle=0, not minIdle

- Original Message -
 From: Hermes Flying flyingher...@yahoo.com
 To: Tomcat Users List users@tomcat.apache.org
 Sent: Wednesday, April 4, 2012 10:45:24 AM
 Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report 
 on memory leaks

 But if I set 'minIdle=0' all the connections would close imediatelly,
 right?
 So why would I need a connection pool in the first place if I do
 this?

  From: Filip Hanik Mailing Lists devli...@hanik.com
 To: Tomcat Users List users@tomcat.apache.org
 Sent: Wednesday, April 4, 2012 7:28 PM
 Subject: Re: Discrepancy between Tomcat's connection pool and
 tomcat's report on memory leaks

 just set minIdle=0 and enable the eviction process to take care of
 it.

 Filip

 - Original Message -
  From: Hermes Flying flyingher...@yahoo.com
  To: Daniel Mikusa dmik...@vmware.com
  Cc: users@tomcat.apache.org
  Sent: Wednesday, April 4, 2012 9:53:30 AM
  Subject: Re: Discrepancy between Tomcat's connection pool and
  tomcat's report on memory leaks

  Which is indicating that the application deployed to
  /GeneralApplication is creating a thread named H2 Log Writer
  GENERICAPPLICATION and never stopping it.  I do not believe
  that this would be associated with the pool created by Tomcat as
  that would be created as a global resource available to all
  applications and not specific to /GeneralApplication.
  I can't really say a whole lot more about what is going on, just
  that this strikes me as odd.  If it were my app, I'd dig into
  this
  more and see what is creating that thread.  Possibly with a
  profiler or thread dumps.

  What is happening here (as I undestand it is the following):
  1) My application uses Tomcat's connection pool from the data
  source
  2) My application uses H2 as a file database. H2 starts back end(s)
  thread which is about logging (H2 logging) and possibly other tasks
   and that is the thread that catalina complaints about
  3) H2 remains open as long as there are open connections and is
  closed when the last connection is released
  4) My application uses Tomcat's connection pool and as a result
  Tomcat decides when the data source should be disposed or when
  connections are released (not my code).
  5) I shutdown Tomcat.
  6) The connection pool of Tomcat has still connections (e.g. idle)
  and so H2 does not shutdown. Hence it's lock file and related
  background threads are still running.
  7) Tomcat shuts down my application but does not dispose off the
  connection pool (yet). I believe this happens because of the way
  Tomcat is being shut down (as sequence of actions I mean).
  8) Since the connection pool has not been disposed, there are still
  connections and as a result H2 is still running
  9) Tomcat's memory leak detection mechanism detects H2 threads
  started from GenericApplication which uses H2 and gives the report
  in catalina.out. So Tomcat gives the report first and then proceeds
  with the shutdown (and this perhaps is not correct? I can't say)
  10) Tomcat eventually shuts down.

  Is this scenario as I describe it, wrong?
  Should I somehow have configured the datasource to be associated
  with my web application instead of a generic data source? Why?
  Should I have shut the data source myself? How?
  If all what I describe is reasonable this seems to me like a
  racing
  condition. How should I mediate this?

  Thank you for your time.

   From: Daniel Mikusa dmik...@vmware.com
  To: Hermes Flying flyingher...@yahoo.com
  Sent: Wednesday, April 4, 2012 5:14 PM
  Subject: Re: Discrepancy between Tomcat's connection pool and
  tomcat's report on memory leaks

  - Original Message -

   What I do is get the dataSource inside a ServletContextListener
   and
   save it in servlet context (as part of a DAO Factory):

   public void contextInitialized(ServletContextEvent sce) {

   ServletContext context = sce.getServletContext();
   DataSource dataSource = null;
   try {
   dataSource = (DataSource) new
   InitialContext().lookup(java:/comp/env/jdbc/GenericDataSource);
   context.setAttribute(daogenericfactory,
   DAOGenericFactory.getInstance(dataSource));

   } catch (NamingException e) {
   e.printStackTrace();
   }

   }

   The DAOGenericFactory just returns specific DAO objects passing
   in
   their constructor the data source.
   Each DAO instance has an member variable of DataSource and

Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks

The real fix to your problem should have been

Resource type=javax.sql.DataSource closeMethod=close .../ (available in 
Tomcat 7)

If I understand the problem you're having is two fold
1. you see reports about memory leaks
started a thread named [H2 File Lock Watchdog you should be able to fix this 
by setting initialSize0 so that the thread is started using the main class 
loader when tomcat starts, not when an app starts using the pool.
(Tomcat 7's jdbc-pool does this automatically from 7.0.27 onwards, regardless 
of configuration)

2. The connection pool is not closed properly, again, this is addressed in the 
top of this email.

letting the pool eventually shrink to 0, is merely a work around, but I realize 
it will NOT work. H2 is starting it's own thread, there is no way around this, 
unless there is way to shut down this thread. Maybe this shuts down if all 
connections are closed.

Filip

- Original Message -
 From: Hermes Flying flyingher...@yahoo.com
 To: Filip Hanik Mailing Lists devli...@hanik.com, Tomcat Users List 
 users@tomcat.apache.org
 Sent: Wednesday, April 4, 2012 10:56:10 AM
 Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report 
 on memory leaks
 
 
 
 Ok. So how is the configuration parameter fixing my problem? Would
 you please explain this to me to undestand how this works?
 
 
 
 
 
 From: Filip Hanik Mailing Lists devli...@hanik.com
 To: Tomcat Users List users@tomcat.apache.org; Hermes Flying
 flyingher...@yahoo.com
 Sent: Wednesday, April 4, 2012 7:50 PM
 Subject: Re: Discrepancy between Tomcat's connection pool and
 tomcat's report on memory leaks
 
 no, that would happen if you set maxIdle=0, not minIdle
 
 - Original Message -
  From: Hermes Flying  flyingher...@yahoo.com 
  To: Tomcat Users List  users@tomcat.apache.org 
  Sent: Wednesday, April 4, 2012 10:45:24 AM
  Subject: Re: Discrepancy between Tomcat's connection pool and
  tomcat's report on memory leaks
  
  But if I set 'minIdle=0' all the connections would close
  imediatelly,
  right?
  So why would I need a connection pool in the first place if I do
  this?
  
  
  
  From: Filip Hanik Mailing Lists  devli...@hanik.com 
  To: Tomcat Users List  users@tomcat.apache.org 
  Sent: Wednesday, April 4, 2012 7:28 PM
  Subject: Re: Discrepancy between Tomcat's connection pool and
  tomcat's report on memory leaks
  
  just set minIdle=0 and enable the eviction process to take care of
  it.
  
  Filip
  
  
  - Original Message -
   From: Hermes Flying  flyingher...@yahoo.com 
   To: Daniel Mikusa  dmik...@vmware.com 
   Cc: users@tomcat.apache.org
   Sent: Wednesday, April 4, 2012 9:53:30 AM
   Subject: Re: Discrepancy between Tomcat's connection pool and
   tomcat's report on memory leaks
   
   Which is indicating that the application deployed to
   /GeneralApplication is creating a thread named H2 Log Writer
   GENERICAPPLICATION and never stopping it. I do not believe
   that this would be associated with the pool created by Tomcat
   as
   that would be created as a global resource available to all
   applications and not specific to /GeneralApplication.
   I can't really say a whole lot more about what is going on,
   just
   that this strikes me as odd. If it were my app, I'd dig into
   this
   more and see what is creating that thread. Possibly with a
   profiler or thread dumps.
   
   What is happening here (as I undestand it is the following):
   1) My application uses Tomcat's connection pool from the data
   source
   2) My application uses H2 as a file database. H2 starts back
   end(s)
   thread which is about logging (H2 logging) and possibly other
   tasks
   and that is the thread that catalina complaints about
   3) H2 remains open as long as there are open connections and is
   closed when the last connection is released
   4) My application uses Tomcat's connection pool and as a result
   Tomcat decides when the data source should be disposed or when
   connections are released (not my code).
   5) I shutdown Tomcat.
   6) The connection pool of Tomcat has still connections (e.g.
   idle)
   and so H2 does not shutdown. Hence it's lock file and related
   background threads are still running.
   7) Tomcat shuts down my application but does not dispose off the
   connection pool (yet). I believe this happens because of the way
   Tomcat is being shut down (as sequence of actions I mean).
   8) Since the connection pool has not been disposed, there are
   still
   connections and as a result H2 is still running
   9) Tomcat's memory leak detection mechanism detects H2 threads
   started from GenericApplication which uses H2 and gives the
   report
   in catalina.out. So Tomcat gives the report first and then
   proceeds
   with the shutdown (and this perhaps is not correct? I can't say)
   10) Tomcat eventually shuts down.
   
   Is this scenario as I describe it, wrong?
   Should I somehow have configured the

Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks

On 04/04/2012 17:14, Hermes Flying wrote:
 Hi Mark,thank you for your reply. 2 questions related your mail 1)I 
 don't understand what you are saying here: but as of 7.0.12 yo an 
 set the closeMethod for a resource that should be the name of a zero 
 atg method to call to shut down the resource. Could you please 
 explain or send a link to a reference on what you are talking about 
 here?

http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Resource_Definitions


 2)Concerning your comment concerning the class loaders and H2. 
 I didn't mention that the H2 driver is under $TOMCAT_HOME/lib. Does 
 this make a difference in the behavior you describe?
Nope. If you are using Tomcat's connection pooling that is where the
driver has to be located.

 I mean the JDBC driver would not be unloaded with the web application, right?
Correct.

 So is this an issue?
No.

 Should I have placed the H2 driver under WEB-INF/lib? 
Not if you wanted to use Tomcat's connection pooling.

 I can do that but then from my point of view Tomcat's setup has many 
 exception/corner cases and the setup is not uniform but requires 
 some background knowledge of the implementation of Tomcat
No you can't since then you can't use Tomcat's connection pooling.


 Also as mentioned to Dan:
 
 My undestanding of what is happening here is the following 1) My 
 application uses Tomcat's connection pool from the data source 2) My 
 application uses H2 as a file database. H2 starts back end(s) thread 
 which is about logging (H2 logging) and possibly other tasks and
 that is the thread that catalina complaints about 3) H2 remains open
 as long as there are open connections and is closed when the last 
 connection is released 4) My application uses Tomcat's connection 
 pool and as a result Tomcat decides when the data source should be 
 disposed or when connections are released (not my code). 5) I 
 shutdown Tomcat. 6) The connection pool of Tomcat has still 
 connections (e.g. idle) and so H2 does not shutdown. Hence it's lock 
 file and related background threads are still running. 7) Tomcat 
 shuts down my application but does not dispose off the connection 
 pool (yet). I believe this happens because of the way Tomcat is
 being shut down (as sequence of actions I mean). 8) Since the
 connection pool has not been disposed, there are still connections
 and as a result H2 is still running 9) Tomcat's memory leak
 detection mechanism detects H2 threads started from
 GenericApplication which uses H2 and gives the report in
 catalina.out. So Tomcat gives the report first and then proceeds with
 the shutdown (and this perhaps is not correct? I can't say) 10)
 Tomcat eventually shuts down.
 
 Is this scenario as I describe it, wrong?

It is mostly right but misses the point that threads started by the JDBC
driver have the web application's class loader as their context class
loader when they should have the class loader used to load the JDBC
driver. That is a bug in the JDBC driver.

 Should I somehow have configured the datasource to be associated with my 
 web application 
 instead of a generic data source?
No.

 Why?
N/A

 Should I have shut the data source myself?
No.

How?
N/A.

If all what I describe is reasonable this seems to me like a racing
condition.
Nope. It is a memory leak in the JDBC driver which is why Tomcat is
reporting it. When a web application shuts down, nothing should be
retaining a reference to the web application class loader. That the JDBC
driver does, is a bug in the JDBC driver.

 How should I mediate this?
Get back to the H2 folks and provide them with a link to this thread. If
they still insist that there is no bug in their driver, either live with
the bug or find an alternative driver and/or database.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Bug in Tomcat AJP Connector?

On 04/04/2012 17:02, Ofer Israeli wrote:
 Hi all,
 
 We have recently witnessed a strange situation.  Our Tomcat (6.0.35)
 listens on 2 ports: 8080 and 8009, handling HTTP and AJP
 respectively.  At some point in time we found that Apache is replying
 HTTP 503s to all clients and a look at netstat showed that indeed
 Apache could not communicate with Tomcat - there were many
 connections in state SYN_SENT, that were never replied.  A test of
 attempting to connect to Tomcat's 8009 port turned out to give the
 same result, so the issue was obviously in Tomcat and not Apache.
 But netstat also showed that Tomcat was listening on port 8009.
 After digging into the logs, we found that there was an Out of Memory
 exception in the JK's accept() sequence and once this exception was
 caught there was a message of terminating thread.
 
 So although the exception is caught and handled by killing the thread
 (isn't that a little drastic?), the socket isn't closed beforehand
 and thus the OS thinks that the port is still fine (in LISTENING
 state), as although the thread is dead, the process is alive.  Has
 anyone encountered this or knows if this bug is known?

Once you have an OOME all bets are off. The JVM needs to be restarted.
There is no guarantee of reliable operation after an OOME.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat6 thread pool questions

2012-04-04 Thread llowder

Forgive me if my first message was unclear.

I have an executor and an AJP connector set up.

Executor name=tomcatThreadPool namePrefix=catalina-exec-
maxThreads=300 minSpareThreads=30/

Connector executor=tomcatThreadPool port=8009
   protocol=org.apache.coyote.ajp.AjpProtocol
   redirectPort=8443/


When I watch it with psi-Probe, I can see that it is indeed killing idle
threads as I expect it to.  What I am not seeing is the minSpareThreads
attribute being honored as I expect it to, though it may very well be that
my understanding of how this is supposed to work is what is wrong.

When I monitor this, I do not see any spare threads being fired up in
advance, nor do I see the thread count being much more than 1 or 2 higher
than the busy thread count.

If I have minSpareThread set to 30, shouldn't that mean that the server
keeps at least 30 non active threads around?

Or is it that I am just looking at the wrong thing or using the wrong tool?

Lee Lowder
O'Reilly Auto Parts
Web Systems Administrator
(417) 862-2674 x1858

This communication and any attachments are confidential, protected by 
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended 
recipient, and may contain legally privileged material. If you are not the 
intended recipient, please return or destroy it immediately. Thank you.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat6 - Context - aliases

2012-04-04 Thread Léa Massiot

Ok. So, I found a solution, if I can call that a solution.

- I created a file an_alias_1.xml in /etc/tomcat6/Catalina/localhost/
(the OS being Debian Squeeze).

- Here are the contents of this an_alias_1.xml file:
 Context path=/an_alias_1 docBase=/home/d1 crossContext=true / 

- This Configuration Descriptor is automatically deployed once saved.

- I suppressed the Webapp w's WEB-INF\context.xml I had created.

- I redeployed the Webapp w.

= Now, when a user clicks on any link  a href=/an_alias_1/file_ i.txt
file_ i.txt  /a
it is successfully retrieved.

= What is still problematic to me, is that, when the user clicks on a link,
the context or Webapp changes (from w to an_alias_1).
The resources which are in /home/d1 are available directly by typing the
following URL in a browser:
http://hostname:8080/an_alias_1/file_ i.txt
and not compulsorily through the Webapp w.

Best regards.

Ref. - a useful thread on stackoverflow: 
http://stackoverflow.com/questions/4575562/how-to-set-up-a-different-context-to-point-to-an-external-directory-outside-weba

--
View this message in context: 
http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4687332.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Tomcat6 - Context - aliases

2012-04-04 Thread Caldarale, Charles R

 From: Léa Massiot [mailto:lmhe...@orange.fr] 
 Subject: Re: Tomcat6 - Context - aliases

 Ok. So, I found a solution, if I can call that a solution.

How about a much easier solution: install Tomcat 7.  Easier to configure, 
faster, and more secure.  Stop making your life difficult.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: SEVERE: Unable to start cluster.

2012-04-04 Thread Dhaval Jaiswal

Thanks to all for sharing info. I will test it  come back to you.

Also want to know that after starting session replication there will be a
huge logging in catalina.out for session information. How to minimize it ?

Below are the logs of catalina.out. As per the log it shows that it has
added member 192.168.3.18.

Now we have a tomcat cluster group from 192.168.3.5 to 192.168.3.11.
However it is trying to connect to the 192.168.3.18.


192.168.3.18 is the tomcat of another cluster. Where should i look into to
resolve this. Where to define this limit that it has to share the session
information from 192.168.3.5 to 192.168.3.11.



INFO: Replication member
added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{-64, -88, 3,
18}:4000,{-64, -88, 3, 18},4000, alive=18507474,id={25 -66 -54 110 84 -96
79 -74 -84 -106 122 -65 -121 9 -16 5 }, payload={}, command={}, domain={}, ]
Apr 5, 2012 12:31:10 AM
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
performBasicCheck
INFO: Suspect member, confirmed
alive.[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-64, -88, 3,
18}:4000,{-64, -88, 3, 18},4000, alive=18507474,id={25 -66 -54 110 84 -96
79 -74 -84 -106 122 -65 -121 9 -16 5 }, payload={}, command={}, domain={},
]]
Apr 5, 2012 12:32:10 AM
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-64,
-88, 3, 18}:4000,{-64, -88, 3, 18},4000, alive=18507474,id={25 -66 -54 110
84 -96 79 -74 -84 -106 122 -65 -121 9 -16 5 }, payload={}, command={},
domain={}, ]] message. Will verify.
Apr 5, 2012 12:32:10 AM
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Verification complete. Member still
alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-64, -88, 3,
18}:4000,{-64, -88, 3, 18},4000, alive=18507474,id={25 -66 -54 110 84 -96
79 -74 -84 -106 122 -65 -121 9 -16 5 }, payload={}, command={}, domain={},
]]
Apr 5, 2012 12:32:10 AM
org.apache.catalina.tribes.tipis.AbstractReplicatedMap heartbeat
SEVERE: Unable to send AbstractReplicatedMap.ping message
org.apache.catalina.tribes.ChannelException: Operation has timed out(6
ms.).; Faulty members:tcp://{-64, -88, 3, 18}:4000;









On Wed, Apr 4, 2012 at 8:43 PM, Thomas Rohde t...@ordix.de wrote:

 -Ursprüngliche Nachricht-
 Von:Dhaval Jaiswal dhaval.jais...@via.com
 Gesendet:   Mi 04.04.2012 16:41
 Betreff:SEVERE: Unable to start cluster.
 An: Tomcat Users List users@tomcat.apache.org;
 CC: Shrinivas Devarkonda shrinivas.devarko...@via.com;
  Hi List,
 
  Below is the error we are facing while starting tomcats.
 
  SEVERE: Unable to start cluster.
  org.apache.catalina.tribes.ChannelException: java.net.SocketException:
 Not
  a multicast address; No faulty members identified.
 
 
  Our cluster setting is as below in server.xml
 
 
   Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
  channelSendOptions=6
  Manager className=org.apache.catalina.ha.session.BackupManager
  expireSessionsOnShutdown=false
 notifyListenersOnReplication=true
 mapSendOptions=6/
 
  Channel
  className=org.apache.catalina.tribes.group.GroupChannel
   Membership
  className=org.apache.catalina.tribes.membership.McastService
  address=192.168.3.14
  port=45564
  frequency=500
  dropTime=3/
   Receiver
  className=org.apache.catalina.tribes.transport.nio.NioReceiver
address=auto
port=4000
selectorTimeout=5000
timeout=6
maxThreads=6/
 
   Sender
  className=org.apache.catalina.tribes.transport.ReplicationTransmitter
Transport
  className=org.apache.catalina.tribes.transport.nio.PooledParallelSender
  timeout=6 keepAliveCount=0/
   /Sender
   Interceptor
 
 className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector/
   Interceptor
 
 className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interc
  eptor/
   Interceptor
 
 className=org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor/
  
 /Channel
   Valve className=org.apache.catalina.ha.tcp.ReplicationValve
 
 
 filter=.*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt
  /
   Valve
  className=org.apache.catalina.ha.session.JvmRouteBinderValve/
 ClusterListener
  className=org.apache.catalina.ha.session.ClusterSessionListener/
 ClusterListener
 
 className=org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener/
   /Cluster
 
 
 
  Note: 192.168.3.14 is the IP of backup manager with java  192.168.3.9 is
  the IP address of

Re: Tomcat6 - Context - aliases

2012-04-04 Thread Konstantin Kolinko

2012/4/4 Léa Massiot lmhe...@orange.fr:
 Ok. So, I found a solution, if I can call that a solution.

 - I created a file an_alias_1.xml in /etc/tomcat6/Catalina/localhost/
 (the OS being Debian Squeeze).

 - Here are the contents of this an_alias_1.xml file:
  Context path=/an_alias_1 docBase=/home/d1 crossContext=true / 

You should remove the path attribute when Context is defined in an XML file.

The name of the xml file itself specifies the path, not the attribute.

See Context chapter in configuration reference for details.


 - This Configuration Descriptor is automatically deployed once saved.

 - I suppressed the Webapp w's WEB-INF\context.xml I had created.

 - I redeployed the Webapp w.

 = Now, when a user clicks on any link  a href=/an_alias_1/file_ i.txt
 file_ i.txt  /a
 it is successfully retrieved.

 = What is still problematic to me, is that, when the user clicks on a link,
 the context or Webapp changes (from w to an_alias_1).
 The resources which are in /home/d1 are available directly by typing the
 following URL in a browser:
 http://hostname:8080/an_alias_1/file_ i.txt
 and not compulsorily through the Webapp w.


Best regards.
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: SEVERE: Unable to start cluster.

2012-04-04 Thread Mark Eggers

Comments inline and surrounded by === COMMENT =

- Original Message -

 From: Dhaval Jaiswal dhaval.jais...@via.com
 To: Tomcat Users List users@tomcat.apache.org
 Cc: 
 Sent: Wednesday, April 4, 2012 12:12 PM
 Subject: Re: SEVERE: Unable to start cluster.

T hanks to all for sharing info. I will test it  come back to you.

 Also want to know that after starting session replication there will be a
 huge logging in catalina.out for session information. How to minimize it ?

=== COMMENT =

Did read my other mail concerning how to manage logging? I thought I was pretty 
explicit (and gave an example). If my example for logging.properties was 
unclear, please ask specific questions (to the list).

If you want less logging, then turn down the levels. See the following 
documentation:

http://tomcat.apache.org/tomcat-6.0-doc/logging.html#Using_java.util.logging_(default)

=== COMMENT =

 Below are the logs of catalina.out. As per the log it shows that it has
 added member 192.168.3.18.

 Now we have a tomcat cluster group from 192.168.3.5 to 192.168.3.11.
 However it is trying to connect to the 192.168.3.18.

 192.168.3.18 is the tomcat of another cluster. Where should i look into to
 resolve this. Where to define this limit that it has to share the session
 information from 192.168.3.5 to 192.168.3.11.

=== COMMENT =

From the documentation on the web site at:

http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#Cluster_Information

Membership is established using multicast heartbeats. Hence, if you wish to 
subdivide your clusters, you can do this by changing the multicast IP address 
or port in the Membership element.

In other words, if you want multiple clusters change either the multicast 
address here:

           Membership 
className=org.apache.catalina.tribes.membership.McastService
                        address=228.0.0.4
                        port=45564
                        frequency=500
                        dropTime=3000/

to a different multicast address, or change the port in the above to a 
different port. The multicast address / port establishes the cluster group. The 
above snippet is from one of my server.xml files.

You might also want to read up on how multicasting works.

=== COMMENT =

 INFO: Replication member
 added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{-64, -88, 3,
 18}:4000,{-64, -88, 3, 18},4000, alive=18507474,id={25 -66 -54 110 84 -96
 79 -74 -84 -106 122 -65 -121 9 -16 5 }, payload={}, command={}, domain={}, ]
 Apr 5, 2012 12:31:10 AM
 org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
 performBasicCheck
 INFO: Suspect member, confirmed
 alive.[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-64, -88, 3,
 18}:4000,{-64, -88, 3, 18},4000, alive=18507474,id={25 -66 -54 110 84 -96
 79 -74 -84 -106 122 -65 -121 9 -16 5 }, payload={}, command={}, domain={},
 ]]
 Apr 5, 2012 12:32:10 AM
 org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
 memberDisappeared
 INFO: Received
 memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-64,
 -88, 3, 18}:4000,{-64, -88, 3, 18},4000, alive=18507474,id={25 -66 -54 110
 84 -96 79 -74 -84 -106 122 -65 -121 9 -16 5 }, payload={}, command={},
 domain={}, ]] message. Will verify.
 Apr 5, 2012 12:32:10 AM
 org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
 memberDisappeared
 INFO: Verification complete. Member still
 alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-64, -88, 3,
 18}:4000,{-64, -88, 3, 18},4000, alive=18507474,id={25 -66 -54 110 84 -96
 79 -74 -84 -106 122 -65 -121 9 -16 5 }, payload={}, command={}, domain={},
 ]]
 Apr 5, 2012 12:32:10 AM
 org.apache.catalina.tribes.tipis.AbstractReplicatedMap heartbeat
 SEVERE: Unable to send AbstractReplicatedMap.ping message
 org.apache.catalina.tribes.ChannelException: Operation has timed out(6
 ms.).; Faulty members:tcp://{-64, -88, 3, 18}:4000;

 On Wed, Apr 4, 2012 at 8:43 PM, Thomas Rohde t...@ordix.de wrote:

  -Ursprüngliche Nachricht-
  Von:    Dhaval Jaiswal dhaval.jais...@via.com
  Gesendet:       Mi 04.04.2012 16:41
  Betreff:        SEVERE: Unable to start cluster.
  An:     Tomcat Users List users@tomcat.apache.org;
  CC:     Shrinivas Devarkonda shrinivas.devarko...@via.com;
   Hi List,

   Below is the error we are facing while starting tomcats.

   SEVERE: Unable to start cluster.
   org.apache.catalina.tribes.ChannelException: java.net.SocketException:
  Not
   a multicast address; No faulty members identified.

   Our cluster setting is as below in server.xml

    Cluster 
 className=org.apache.catalina.ha.tcp.SimpleTcpCluster
   channelSendOptions=6
           Manager 
 className=org.apache.catalina.ha.session.BackupManager
   expireSessionsOnShutdown=false

Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks

Thank you for your explanation.
I will take this to H2 but I have one more question on your comment:
 
Nope. It is a memory leak in the JDBC driver which is why Tomcat is reporting 
it. When a web application shuts down, nothing should be
retaining a reference to the web application class loader. That the JDBC 
driver does, is a bug in the JDBC driver.
 
My question is: is this leak a general problem that should concern me or 
something that is an issue only on application undeployment? 


 
 


 From: Mark Thomas ma...@apache.org
To: Tomcat Users List users@tomcat.apache.org 
Sent: Wednesday, April 4, 2012 8:12 PM
Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report 
on memory leaks
  
On 04/04/2012 17:14, Hermes Flying wrote:
 Hi Mark,thank you for your reply. 2 questions related your mail 1)I 
 don't understand what you are saying here: but as of 7.0.12 yo an 
 set the closeMethod for a resource that should be the name of a zero 
 atg method to call to shut down the resource. Could you please 
 explain or send a link to a reference on what you are talking about 
 here?

http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Resource_Definitions


 2)Concerning your comment concerning the class loaders and H2. 
 I didn't mention that the H2 driver is under $TOMCAT_HOME/lib. Does 
 this make a difference in the behavior you describe?
Nope. If you are using Tomcat's connection pooling that is where the
driver has to be located.

 I mean the JDBC driver would not be unloaded with the web application, right?
Correct.

 So is this an issue?
No.

 Should I have placed the H2 driver under WEB-INF/lib? 
Not if you wanted to use Tomcat's connection pooling.

 I can do that but then from my point of view Tomcat's setup has many 
 exception/corner cases and the setup is not uniform but requires 
 some background knowledge of the implementation of Tomcat
No you can't since then you can't use Tomcat's connection pooling.


 Also as mentioned to Dan:
 
 My undestanding of what is happening here is the following 1) My 
 application uses Tomcat's connection pool from the data source 2) My 
 application uses H2 as a file database. H2 starts back end(s) thread 
 which is about logging (H2 logging) and possibly other tasks and
 that is the thread that catalina complaints about 3) H2 remains open
 as long as there are open connections and is closed when the last 
 connection is released 4) My application uses Tomcat's connection 
 pool and as a result Tomcat decides when the data source should be 
 disposed or when connections are released (not my code). 5) I 
 shutdown Tomcat. 6) The connection pool of Tomcat has still 
 connections (e.g. idle) and so H2 does not shutdown. Hence it's lock 
 file and related background threads are still running. 7) Tomcat 
 shuts down my application but does not dispose off the connection 
 pool (yet). I believe this happens because of the way Tomcat is
 being shut down (as sequence of actions I mean). 8) Since the
 connection pool has not been disposed, there are still connections
 and as a result H2 is still running 9) Tomcat's memory leak
 detection mechanism detects H2 threads started from
 GenericApplication which uses H2 and gives the report in
 catalina.out. So Tomcat gives the report first and then proceeds with
 the shutdown (and this perhaps is not correct? I can't say) 10)
 Tomcat eventually shuts down.
 
 Is this scenario as I describe it, wrong?

It is mostly right but misses the point that threads started by the JDBC
driver have the web application's class loader as their context class
loader when they should have the class loader used to load the JDBC
driver. That is a bug in the JDBC driver.

 Should I somehow have configured the datasource to be associated with my 
 web application 
 instead of a generic data source?
No.

 Why?
N/A

 Should I have shut the data source myself?
No.

How?
N/A.

If all what I describe is reasonable this seems to me like a racing
condition.
Nope. It is a memory leak in the JDBC driver which is why Tomcat is
reporting it. When a web application shuts down, nothing should be
retaining a reference to the web application class loader. That the JDBC
driver does, is a bug in the JDBC driver.

 How should I mediate this?
Get back to the H2 folks and provide them with a link to this thread. If
they still insist that there is no bug in their driver, either live with
the bug or find an alternative driver and/or database.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks