You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Robert Anderson <ra...@gmail.com> on 2015/01/30 18:19:04 UTC
tomcat-jdbc PoolCleaner deadlock
Every day we are getting deadlocks like that:
Found one Java-level deadlock:
=============================
"ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 -
DB:DATASOURCE(java:/comp/env/jdbc/cacheapp)":
waiting to lock monitor 0x000000001504e6d8 (object 0x000000071ba001d0, a
com.intersys.jdbc.CacheConnection),
which is held by "PoolCleaner[1070846187:1422601344160]"
"PoolCleaner[1070846187:1422601344160]":
waiting to lock monitor 0x0000000012ce77e8 (object 0x000000071ba007f0, a
com.intersys.jdbc.CacheConnection$MessageCount),
which is held by "ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 -
DB:DATASOURCE(java:/comp/env/jdbc/cacheapp)"
Are there anything that we can do to avoid it?
Server version: Apache Tomcat/7.0.57
Server built: Nov 3 2014 08:39:16 UTC
Server number: 7.0.57.0
OS Name: Linux
OS Version: 2.6.18-194.17.1.el5
Architecture: amd64
JVM Version: 1.7.0_71-b14
JVM Vendor: Oracle Corporation
Datasource definition:
<Resource name="jdbc/cacheapp" auth="Container" type="javax.sql.DataSource"
removeAbandoned="true" removeAbandonedTimeout="300"
maxActive="120" maxIdle="20" minIdle="1"
maxWait="10000"
validationQuery="select 1"
testOnBorrow="true"
validationInterval="0"
fairQueue="false"
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
alternateUsernameAllowed="true"
username="user" password="password"
driverClassName="com.intersys.jdbc.CacheDriver"
url="jdbc:Cache://myserver:1972/Namespace"/>
Thanks in advance.
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Robert Anderson <ra...@gmail.com>.
Thanks, Chris.
In general, I would expect validationInterval="0" to disable
validation, but the documentation does not say anything about a zero
value. Is it possible that you are /constantly/ validating? If you
change that number to something higher (in ms: maybe "10000" for 10s)
you will reduce the chance for this deadlock?
"0" means "validate on every connection request". I need this setting
because the apps has some annoying bugs ("zn" - change namespaces in Caché
and there are many legacy apps that do not catch expceptions very well)
There is a flaw in the documentation surrounding this setting on
Linux, but it's only when fairQueue="true", so it shouldn't matter for
you. But you might want to consider leaving the queue "fair". It's not
clear from the documentation whether enabling queue fairness
/decreases/ performance or the opposite (but it seems reasonable that
enforcing queue fairness would probably decrease performance).
The same problem happens with fairQueue=true. :(
2015-01-30 14:31 GMT-03:00 Christopher Schultz <chris@christopherschultz.net
>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Robert,
>
> On 1/30/15 12:19 PM, Robert Anderson wrote:
> > Every day we are getting deadlocks like that:
> >
> > Found one Java-level deadlock: =============================
> > "ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 -
> > DB:DATASOURCE(java:/comp/env/jdbc/cacheapp)": waiting to lock
> > monitor 0x000000001504e6d8 (object 0x000000071ba001d0, a
> > com.intersys.jdbc.CacheConnection), which is held by
> > "PoolCleaner[1070846187:1422601344160]"
> > "PoolCleaner[1070846187:1422601344160]": waiting to lock monitor
> > 0x0000000012ce77e8 (object 0x000000071ba007f0, a
> > com.intersys.jdbc.CacheConnection$MessageCount), which is held by
> > "ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 -
> > DB:DATASOURCE(java:/comp/env/jdbc/cacheapp)"
>
> D'oh.
>
> > Are there anything that we can do to avoid it?
> >
> >
> > Server version: Apache Tomcat/7.0.57 Server built: Nov 3 2014
> > 08:39:16 UTC Server number: 7.0.57.0 OS Name: Linux OS
> > Version: 2.6.18-194.17.1.el5 Architecture: amd64 JVM Version:
> > 1.7.0_71-b14 JVM Vendor: Oracle Corporation
> >
> >
> > Datasource definition:
> >
> > <Resource name="jdbc/cacheapp" auth="Container"
> > type="javax.sql.DataSource" removeAbandoned="true"
> > removeAbandonedTimeout="300" maxActive="120" maxIdle="20"
> > minIdle="1" maxWait="10000" validationQuery="select 1"
> > testOnBorrow="true" validationInterval="0"
>
> In general, I would expect validationInterval="0" to disable
> validation, but the documentation does not say anything about a zero
> value. Is it possible that you are /constantly/ validating? If you
> change that number to something higher (in ms: maybe "10000" for 10s)
> you will reduce the chance for this deadlock?
>
> I suspect this is a bug (deadlock should not occur), but you can maybe
> avoid it by changing your configuration.
>
> > fairQueue="false"
>
> There is a flaw in the documentation surrounding this setting on
> Linux, but it's only when fairQueue="true", so it shouldn't matter for
> you. But you might want to consider leaving the queue "fair". It's not
> clear from the documentation whether enabling queue fairness
> /decreases/ performance or the opposite (but it seems reasonable that
> enforcing queue fairness would probably decrease performance).
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJUy7/vAAoJEBzwKT+lPKRYCGwP/ijUIjnHQ39rE6qzZ9GIGwad
> ZkGQTFZlZw03yxkcu9Dzqb7LdN/RWHaHzi5jZyWkJnz7SO6EIe9gyUya2kvojF4x
> 9u3+TrDT/+fTQd17UvEuKAzRqV56PGFdfWGMNlQmk1ndOQYFRwD6B3vFF0SCMbw0
> q0Z5qIHw5YqgVg+xfsA/ubsrOX8prI0c0AzgN8yFd5Jv+Ts80rD4PNr1kfN+K6oE
> N2komJkEEn3PpSSFdhut3FPcZZingm5xiV/2u5hwOOvHhAZIG7qpP0RwEDN2fPRd
> MEC1j0dO2k+JZW8PC5RWPGyqEg9F+213sw8Qc8idOf2zHNXYwzxtZcD8i+iokYLS
> 8Tn5ByYRgX5ZEdTA1e1DUIM6BTRgA+HX30T5lRBOBFC9/baKcrRVR9tS9gn9zQBj
> HV1Xfoy6V/efL7AHAOd1nPL+SswzVYs2U0HtOOA4MjYLguhuRNPx3ofWufESXJ1T
> 5n6h7ipN1mda8LcMtK3bVSrBfL+SnU5p7bwmQvtRX33xeKMOgv8XnWWaFc1eWLHg
> yrS6KZSVUhIHlLwy2tBJasWB2VtxcEOoSjOWJfHBgPIsAp3TcwyNbNZ3JVDAMW1D
> 8kjmDJnBguuHbz+tn4qabPB8TmcO/78GrcOr+qY42IjIJQM4kX0otXzngh+nI21z
> Fm3UQnSzGs29jQCwe5Ho
> =v9Pk
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Robert,
On 1/30/15 12:19 PM, Robert Anderson wrote:
> Every day we are getting deadlocks like that:
>
> Found one Java-level deadlock: =============================
> "ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 -
> DB:DATASOURCE(java:/comp/env/jdbc/cacheapp)": waiting to lock
> monitor 0x000000001504e6d8 (object 0x000000071ba001d0, a
> com.intersys.jdbc.CacheConnection), which is held by
> "PoolCleaner[1070846187:1422601344160]"
> "PoolCleaner[1070846187:1422601344160]": waiting to lock monitor
> 0x0000000012ce77e8 (object 0x000000071ba007f0, a
> com.intersys.jdbc.CacheConnection$MessageCount), which is held by
> "ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 -
> DB:DATASOURCE(java:/comp/env/jdbc/cacheapp)"
D'oh.
> Are there anything that we can do to avoid it?
>
>
> Server version: Apache Tomcat/7.0.57 Server built: Nov 3 2014
> 08:39:16 UTC Server number: 7.0.57.0 OS Name: Linux OS
> Version: 2.6.18-194.17.1.el5 Architecture: amd64 JVM Version:
> 1.7.0_71-b14 JVM Vendor: Oracle Corporation
>
>
> Datasource definition:
>
> <Resource name="jdbc/cacheapp" auth="Container"
> type="javax.sql.DataSource" removeAbandoned="true"
> removeAbandonedTimeout="300" maxActive="120" maxIdle="20"
> minIdle="1" maxWait="10000" validationQuery="select 1"
> testOnBorrow="true" validationInterval="0"
In general, I would expect validationInterval="0" to disable
validation, but the documentation does not say anything about a zero
value. Is it possible that you are /constantly/ validating? If you
change that number to something higher (in ms: maybe "10000" for 10s)
you will reduce the chance for this deadlock?
I suspect this is a bug (deadlock should not occur), but you can maybe
avoid it by changing your configuration.
> fairQueue="false"
There is a flaw in the documentation surrounding this setting on
Linux, but it's only when fairQueue="true", so it shouldn't matter for
you. But you might want to consider leaving the queue "fair". It's not
clear from the documentation whether enabling queue fairness
/decreases/ performance or the opposite (but it seems reasonable that
enforcing queue fairness would probably decrease performance).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUy7/vAAoJEBzwKT+lPKRYCGwP/ijUIjnHQ39rE6qzZ9GIGwad
ZkGQTFZlZw03yxkcu9Dzqb7LdN/RWHaHzi5jZyWkJnz7SO6EIe9gyUya2kvojF4x
9u3+TrDT/+fTQd17UvEuKAzRqV56PGFdfWGMNlQmk1ndOQYFRwD6B3vFF0SCMbw0
q0Z5qIHw5YqgVg+xfsA/ubsrOX8prI0c0AzgN8yFd5Jv+Ts80rD4PNr1kfN+K6oE
N2komJkEEn3PpSSFdhut3FPcZZingm5xiV/2u5hwOOvHhAZIG7qpP0RwEDN2fPRd
MEC1j0dO2k+JZW8PC5RWPGyqEg9F+213sw8Qc8idOf2zHNXYwzxtZcD8i+iokYLS
8Tn5ByYRgX5ZEdTA1e1DUIM6BTRgA+HX30T5lRBOBFC9/baKcrRVR9tS9gn9zQBj
HV1Xfoy6V/efL7AHAOd1nPL+SswzVYs2U0HtOOA4MjYLguhuRNPx3ofWufESXJ1T
5n6h7ipN1mda8LcMtK3bVSrBfL+SnU5p7bwmQvtRX33xeKMOgv8XnWWaFc1eWLHg
yrS6KZSVUhIHlLwy2tBJasWB2VtxcEOoSjOWJfHBgPIsAp3TcwyNbNZ3JVDAMW1D
8kjmDJnBguuHbz+tn4qabPB8TmcO/78GrcOr+qY42IjIJQM4kX0otXzngh+nI21z
Fm3UQnSzGs29jQCwe5Ho
=v9Pk
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 30.01.2015 um 18:44 schrieb Robert Anderson:
> Could you post a full stacktrace, or threaddump?
>
> "ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 -
> DB:DATASOURCE(java:/comp/env/jdbc/cacheapp)" daemon prio=10
> tid=0x0000000013bb0000 nid=0x7a6d waiting for monitor entry
> [0x000000005125b000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at com.intersys.jdbc.CacheConnection.close(CacheConnection.java:552)
> - waiting to lock <0x000000071ba001d0> (a
> com.intersys.jdbc.CacheConnection)
> at
> com.intersys.jdbc.InStream.invalidMessageReceived(InStream.java:234)
> - locked <0x000000071ba094c0> (a com.intersys.jdbc.InStream)
> at com.intersys.jdbc.InStream.checkHeader(InStream.java:104)
> - eliminated <0x000000071ba094c0> (a com.intersys.jdbc.InStream)
> at com.intersys.jdbc.InStream.readHeader(InStream.java:148)
> - locked <0x000000071ba094c0> (a com.intersys.jdbc.InStream)
> at
> com.intersys.jdbc.CacheStatement.sendDirectQueryRequest(CacheStatement.java:551)
> - locked <0x000000071ba007f0> (a
> com.intersys.jdbc.CacheConnection$MessageCount)
> - locked <0x000000071ba00150> (a com.intersys.jdbc.CacheStatement)
> at com.intersys.jdbc.CacheStatement.Query(CacheStatement.java:486)
> - locked <0x000000071ba00150> (a com.intersys.jdbc.CacheStatement)
> at
> com.intersys.jdbc.CacheStatement.executeQuery(CacheStatement.java:418)
> - locked <0x000000071ba00150> (a com.intersys.jdbc.CacheStatement)
> at
> br.com.itx.database.impl.ConnectionSql.execute(ConnectionSql.java:246)
> at
> br.com.itx.integration.DatabaseHandler.execute(DatabaseHandler.java:274)
> at
> br.com.itx.integration.DatabaseHandler.execute(DatabaseHandler.java:163)
> at
> br.com.itx.engine.CoreObjectElement.execute(CoreObjectElement.java:88)
> at
> br.com.itx.component.taglib.ExecuteCore.doStartTag(ExecuteCore.java:98)
> at
> org.apache.jsp.portaladv.main_005fpre_jsp._jspx_meth_w_005fexecuteCore_005f41(main_005fpre_jsp.java:2858)
> at
> org.apache.jsp.portaladv.main_005fpre_jsp._jspService(main_005fpre_jsp.java:718)
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> at
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:748)
> at
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:604)
> at
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:543)
> at br.com.itx.engine.Execute.doJsp(Execute.java:476)
> at br.com.itx.engine.Execute.doPost(Execute.java:425)
> - locked <0x000000071ba34398> (a java.lang.Object)
> at br.com.itx.engine.Execute.doGet(Execute.java:98)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:620)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
> at
> com.googlecode.psiprobe.Tomcat70AgentValve.invoke(Tomcat70AgentValve.java:38)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
> at
> org.apache.catalina.valves.StuckThreadDetectionValve.invoke(StuckThreadDetectionValve.java:221)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:421)
> at
> org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:188)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
> at
> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2466)
> at
> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2455)
> - locked <0x000000071b7df138> (a
> org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
> "PoolCleaner[1070846187:1422601344160]" daemon prio=10
> tid=0x0000000013306800 nid=0x71e0 waiting for monitor entry
> [0x00000000417fd000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at com.intersys.jdbc.CacheConnection.close(CacheConnection.java:566)
> - waiting to lock <0x000000071ba007f0> (a
> com.intersys.jdbc.CacheConnection$MessageCount)
> - locked <0x000000071ba001d0> (a com.intersys.jdbc.CacheConnection)
> at
> org.apache.tomcat.jdbc.pool.PooledConnection.disconnect(PooledConnection.java:331)
> at
> org.apache.tomcat.jdbc.pool.PooledConnection.release(PooledConnection.java:495)
> at
> org.apache.tomcat.jdbc.pool.ConnectionPool.release(ConnectionPool.java:582)
> at
> org.apache.tomcat.jdbc.pool.ConnectionPool.abandon(ConnectionPool.java:541)
> at
> org.apache.tomcat.jdbc.pool.ConnectionPool.checkAbandoned(ConnectionPool.java:956)
> at
> org.apache.tomcat.jdbc.pool.ConnectionPool$PoolCleaner.run(ConnectionPool.java:1345)
> at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
Do you hold your connections longer then 300 seconds? If you hold long
onto your connections and still want to use removeAbandoned, you should
probably try the ResetAbandonedTimer interceptor to reset the timer on
each action you are doing on the connection.
Felix
>
>
> Are there any exceptions logged before?
>
> There are many exceptions every day (invalid parameters, syntax error, ...)
>
>
> 2015-01-30 14:33 GMT-03:00 Felix Schumacher <
> felix.schumacher@internetallee.de>:
>
>> Am 30.01.2015 um 18:19 schrieb Robert Anderson:
>>
>>> Every day we are getting deadlocks like that:
>>>
>>> Found one Java-level deadlock:
>>> =============================
>>> "ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 -
>>> DB:DATASOURCE(java:/comp/env/jdbc/cacheapp)":
>>> waiting to lock monitor 0x000000001504e6d8 (object 0x000000071ba001d0,
>>> a
>>> com.intersys.jdbc.CacheConnection),
>>> which is held by "PoolCleaner[1070846187:1422601344160]"
>>> "PoolCleaner[1070846187:1422601344160]":
>>> waiting to lock monitor 0x0000000012ce77e8 (object 0x000000071ba007f0,
>>> a
>>> com.intersys.jdbc.CacheConnection$MessageCount),
>>> which is held by "ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 -
>>> DB:DATASOURCE(java:/comp/env/jdbc/cacheapp)"
>>>
>> Could you post a full stacktrace, or threaddump?
>>
>> Are there any exceptions logged before?
>>
>> Regards
>> Felix
>>
>>>
>>> Are there anything that we can do to avoid it?
>>>
>>>
>>> Server version: Apache Tomcat/7.0.57
>>> Server built: Nov 3 2014 08:39:16 UTC
>>> Server number: 7.0.57.0
>>> OS Name: Linux
>>> OS Version: 2.6.18-194.17.1.el5
>>> Architecture: amd64
>>> JVM Version: 1.7.0_71-b14
>>> JVM Vendor: Oracle Corporation
>>>
>>>
>>> Datasource definition:
>>>
>>> <Resource name="jdbc/cacheapp" auth="Container"
>>> type="javax.sql.DataSource"
>>> removeAbandoned="true" removeAbandonedTimeout="300"
>>> maxActive="120" maxIdle="20"
>>> minIdle="1"
>>> maxWait="10000"
>>> validationQuery="select 1"
>>> testOnBorrow="true"
>>> validationInterval="0"
>>> fairQueue="false"
>>>
>>> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
>>> alternateUsernameAllowed="true"
>>> username="user" password="password"
>>> driverClassName="com.intersys.jdbc.CacheDriver"
>>>
>>> url="jdbc:Cache://myserver:1972/Namespace"/>
>>>
>>>
>>> Thanks in advance.
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Filip Hanik <fi...@hanik.com>.
thank you Robert!
On Fri, Feb 6, 2015 at 11:14 AM, Robert Anderson <ra...@gmail.com> wrote:
> Hi,
>
> After a full week of normal usage, no deadlocks were found.
>
>
> Thank you very much.
>
> Robert
>
>
>
> 2015-01-30 16:38 GMT-03:00 Robert Anderson <ra...@gmail.com>:
>
> > Ok, Filip!
> >
> > Thanks,
> >
> > Robert
> >
> > 2015-01-30 16:31 GMT-03:00 Filip Hanik <fi...@hanik.com>:
> >
> > Robert, kindly let us know if disabling the pool cleaner does resolve
> your
> >> dead lock
> >>
> >> Filip
> >>
> >>
> >> On Fri, Jan 30, 2015 at 12:25 PM, Robert Anderson <ra...@gmail.com>
> >> wrote:
> >>
> >> > Great, Filip!
> >> >
> >> > "Returns true if the pool sweeper is enabled for the connection pool.
> >> The
> >> > pool sweeper is enabled if any settings that require async
> intervention
> >> in
> >> > the pool are turned on boolean result =
> >> > getTimeBetweenEvictionRunsMillis()>0; result = result &&
> >> > (isRemoveAbandoned() && getRemoveAbandonedTimeout()>0); result =
> result
> >> ||
> >> > (isTestWhileIdle() && getValidationQuery()!=null); return result;" [1]
> >> >
> >> > Best regards.
> >> >
> >> >
> >> > [1]
> >> >
> >> >
> >>
> https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/tomcat/jdbc/pool/PoolConfiguration.html#isPoolSweeperEnabled()
> >> >
> >> > 2015-01-30 16:13 GMT-03:00 Filip Hanik <fi...@hanik.com>:
> >> >
> >> > > Are you seeing that message, cause it seems to be a defensive check,
> >> but
> >> > > wouldn't happen due to
> >> > >
> >> > > 509 public void initializePoolCleaner(PoolConfiguration properties)
> {
> >> 510
> >> > > //if
> >> > > the evictor thread is supposed to run, start it now 511 if
> >> (properties.
> >> > > isPoolSweeperEnabled()) { 512 poolCleaner = new PoolCleaner(this,
> >> > > properties
> >> > > .getTimeBetweenEvictionRunsMillis()); 513 poolCleaner.start(); 514 }
> >> > //end
> >> > > if 515 }
> >> > >
> >> > > On Fri, Jan 30, 2015 at 12:05 PM, Robert Anderson <
> ranomail@gmail.com
> >> >
> >> > > wrote:
> >> > >
> >> > > > Filip,
> >> > > >
> >> > > > timeBetweenEvictionRunsMillis=0 does not disable PoolCleaner [1].
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > >
> >> > > > if (sleepTime <= 0) {
> >> > > > log.warn("Database connection pool evicter thread
> >> > > > interval is set to 0, defaulting to 30 seconds");
> >> > > > this.sleepTime = 1000 * 30;
> >> > > > } else if (sleepTime < 1000) {
> >> > > > log.warn("Database connection pool evicter thread
> >> > > > interval is set to lower than 1 second.");
> >> > > > }
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > >
> >> > > >
> >> > > > [1]
> >> > > >
> >> > >
> >> >
> >>
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
> >> > > >
> >> > > >
> >> > > > 2015-01-30 15:17 GMT-03:00 Robert Anderson <ra...@gmail.com>:
> >> > > >
> >> > > > > Sorry,
> >> > > > >
> >> > > > > [1] https://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
> >> > > > >
> >> > > > > 2015-01-30 15:15 GMT-03:00 Robert Anderson <ranomail@gmail.com
> >:
> >> > > > >
> >> > > > > Filip,
> >> > > > >>
> >> > > > >> however, disabling the pool cleaner it should yield better
> >> results.
> >> > > > >>
> >> > > > >> The documention[1] says:
> >> > > > >>
> >> > > > >> "This value should not be set under 1 second"
> >> > > > >>
> >> > > > >> Isn't true?
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >> 2015-01-30 15:07 GMT-03:00 Filip Hanik <fi...@hanik.com>:
> >> > > > >>
> >> > > > >> Looking at the locks that are involved in the dead lock, it's
> >> all in
> >> > > the
> >> > > > >>> intersys traces. Furthermore, it seems as intersys may already
> >> be
> >> > > doing
> >> > > > >>> pooling inside the driver. If that is the case, you have two
> >> > options
> >> > > > >>>
> >> > > > >>> 1. disable pooling in intersys OR
> >> > > > >>> 2. don't use tomcat's jdbc pool since intersys already does
> >> pooling
> >> > > > >>>
> >> > > > >>> however, disabling the pool cleaner it should yield better
> >> results.
> >> > > > >>>
> >> > > > >>> On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik <
> filip@hanik.com>
> >> > > wrote:
> >> > > > >>>
> >> > > > >>> > Disable the pool cleaner
> >> > > > >>> >
> >> > > > >>> > timeBetweenEvictionRunsMillis=0
> >> > > > >>> >
> >> > > > >>> >
> >> > > > >>> >
> >> > > > >>>
> >> > > > >>
> >> > > > >>
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Robert Anderson <ra...@gmail.com>.
Hi,
After a full week of normal usage, no deadlocks were found.
Thank you very much.
Robert
2015-01-30 16:38 GMT-03:00 Robert Anderson <ra...@gmail.com>:
> Ok, Filip!
>
> Thanks,
>
> Robert
>
> 2015-01-30 16:31 GMT-03:00 Filip Hanik <fi...@hanik.com>:
>
> Robert, kindly let us know if disabling the pool cleaner does resolve your
>> dead lock
>>
>> Filip
>>
>>
>> On Fri, Jan 30, 2015 at 12:25 PM, Robert Anderson <ra...@gmail.com>
>> wrote:
>>
>> > Great, Filip!
>> >
>> > "Returns true if the pool sweeper is enabled for the connection pool.
>> The
>> > pool sweeper is enabled if any settings that require async intervention
>> in
>> > the pool are turned on boolean result =
>> > getTimeBetweenEvictionRunsMillis()>0; result = result &&
>> > (isRemoveAbandoned() && getRemoveAbandonedTimeout()>0); result = result
>> ||
>> > (isTestWhileIdle() && getValidationQuery()!=null); return result;" [1]
>> >
>> > Best regards.
>> >
>> >
>> > [1]
>> >
>> >
>> https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/tomcat/jdbc/pool/PoolConfiguration.html#isPoolSweeperEnabled()
>> >
>> > 2015-01-30 16:13 GMT-03:00 Filip Hanik <fi...@hanik.com>:
>> >
>> > > Are you seeing that message, cause it seems to be a defensive check,
>> but
>> > > wouldn't happen due to
>> > >
>> > > 509 public void initializePoolCleaner(PoolConfiguration properties) {
>> 510
>> > > //if
>> > > the evictor thread is supposed to run, start it now 511 if
>> (properties.
>> > > isPoolSweeperEnabled()) { 512 poolCleaner = new PoolCleaner(this,
>> > > properties
>> > > .getTimeBetweenEvictionRunsMillis()); 513 poolCleaner.start(); 514 }
>> > //end
>> > > if 515 }
>> > >
>> > > On Fri, Jan 30, 2015 at 12:05 PM, Robert Anderson <ranomail@gmail.com
>> >
>> > > wrote:
>> > >
>> > > > Filip,
>> > > >
>> > > > timeBetweenEvictionRunsMillis=0 does not disable PoolCleaner [1].
>> > > >
>> > >
>> > >
>> > >
>> > > >
>> > > > if (sleepTime <= 0) {
>> > > > log.warn("Database connection pool evicter thread
>> > > > interval is set to 0, defaulting to 30 seconds");
>> > > > this.sleepTime = 1000 * 30;
>> > > > } else if (sleepTime < 1000) {
>> > > > log.warn("Database connection pool evicter thread
>> > > > interval is set to lower than 1 second.");
>> > > > }
>> > > >
>> > >
>> > >
>> > >
>> > > >
>> > > >
>> > > > [1]
>> > > >
>> > >
>> >
>> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
>> > > >
>> > > >
>> > > > 2015-01-30 15:17 GMT-03:00 Robert Anderson <ra...@gmail.com>:
>> > > >
>> > > > > Sorry,
>> > > > >
>> > > > > [1] https://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
>> > > > >
>> > > > > 2015-01-30 15:15 GMT-03:00 Robert Anderson <ra...@gmail.com>:
>> > > > >
>> > > > > Filip,
>> > > > >>
>> > > > >> however, disabling the pool cleaner it should yield better
>> results.
>> > > > >>
>> > > > >> The documention[1] says:
>> > > > >>
>> > > > >> "This value should not be set under 1 second"
>> > > > >>
>> > > > >> Isn't true?
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> 2015-01-30 15:07 GMT-03:00 Filip Hanik <fi...@hanik.com>:
>> > > > >>
>> > > > >> Looking at the locks that are involved in the dead lock, it's
>> all in
>> > > the
>> > > > >>> intersys traces. Furthermore, it seems as intersys may already
>> be
>> > > doing
>> > > > >>> pooling inside the driver. If that is the case, you have two
>> > options
>> > > > >>>
>> > > > >>> 1. disable pooling in intersys OR
>> > > > >>> 2. don't use tomcat's jdbc pool since intersys already does
>> pooling
>> > > > >>>
>> > > > >>> however, disabling the pool cleaner it should yield better
>> results.
>> > > > >>>
>> > > > >>> On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik <fi...@hanik.com>
>> > > wrote:
>> > > > >>>
>> > > > >>> > Disable the pool cleaner
>> > > > >>> >
>> > > > >>> > timeBetweenEvictionRunsMillis=0
>> > > > >>> >
>> > > > >>> >
>> > > > >>> >
>> > > > >>>
>> > > > >>
>> > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Robert Anderson <ra...@gmail.com>.
Ok, Filip!
Thanks,
Robert
2015-01-30 16:31 GMT-03:00 Filip Hanik <fi...@hanik.com>:
> Robert, kindly let us know if disabling the pool cleaner does resolve your
> dead lock
>
> Filip
>
>
> On Fri, Jan 30, 2015 at 12:25 PM, Robert Anderson <ra...@gmail.com>
> wrote:
>
> > Great, Filip!
> >
> > "Returns true if the pool sweeper is enabled for the connection pool. The
> > pool sweeper is enabled if any settings that require async intervention
> in
> > the pool are turned on boolean result =
> > getTimeBetweenEvictionRunsMillis()>0; result = result &&
> > (isRemoveAbandoned() && getRemoveAbandonedTimeout()>0); result = result
> ||
> > (isTestWhileIdle() && getValidationQuery()!=null); return result;" [1]
> >
> > Best regards.
> >
> >
> > [1]
> >
> >
> https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/tomcat/jdbc/pool/PoolConfiguration.html#isPoolSweeperEnabled()
> >
> > 2015-01-30 16:13 GMT-03:00 Filip Hanik <fi...@hanik.com>:
> >
> > > Are you seeing that message, cause it seems to be a defensive check,
> but
> > > wouldn't happen due to
> > >
> > > 509 public void initializePoolCleaner(PoolConfiguration properties) {
> 510
> > > //if
> > > the evictor thread is supposed to run, start it now 511 if (properties.
> > > isPoolSweeperEnabled()) { 512 poolCleaner = new PoolCleaner(this,
> > > properties
> > > .getTimeBetweenEvictionRunsMillis()); 513 poolCleaner.start(); 514 }
> > //end
> > > if 515 }
> > >
> > > On Fri, Jan 30, 2015 at 12:05 PM, Robert Anderson <ra...@gmail.com>
> > > wrote:
> > >
> > > > Filip,
> > > >
> > > > timeBetweenEvictionRunsMillis=0 does not disable PoolCleaner [1].
> > > >
> > >
> > >
> > >
> > > >
> > > > if (sleepTime <= 0) {
> > > > log.warn("Database connection pool evicter thread
> > > > interval is set to 0, defaulting to 30 seconds");
> > > > this.sleepTime = 1000 * 30;
> > > > } else if (sleepTime < 1000) {
> > > > log.warn("Database connection pool evicter thread
> > > > interval is set to lower than 1 second.");
> > > > }
> > > >
> > >
> > >
> > >
> > > >
> > > >
> > > > [1]
> > > >
> > >
> >
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
> > > >
> > > >
> > > > 2015-01-30 15:17 GMT-03:00 Robert Anderson <ra...@gmail.com>:
> > > >
> > > > > Sorry,
> > > > >
> > > > > [1] https://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
> > > > >
> > > > > 2015-01-30 15:15 GMT-03:00 Robert Anderson <ra...@gmail.com>:
> > > > >
> > > > > Filip,
> > > > >>
> > > > >> however, disabling the pool cleaner it should yield better
> results.
> > > > >>
> > > > >> The documention[1] says:
> > > > >>
> > > > >> "This value should not be set under 1 second"
> > > > >>
> > > > >> Isn't true?
> > > > >>
> > > > >>
> > > > >>
> > > > >> 2015-01-30 15:07 GMT-03:00 Filip Hanik <fi...@hanik.com>:
> > > > >>
> > > > >> Looking at the locks that are involved in the dead lock, it's all
> in
> > > the
> > > > >>> intersys traces. Furthermore, it seems as intersys may already be
> > > doing
> > > > >>> pooling inside the driver. If that is the case, you have two
> > options
> > > > >>>
> > > > >>> 1. disable pooling in intersys OR
> > > > >>> 2. don't use tomcat's jdbc pool since intersys already does
> pooling
> > > > >>>
> > > > >>> however, disabling the pool cleaner it should yield better
> results.
> > > > >>>
> > > > >>> On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik <fi...@hanik.com>
> > > wrote:
> > > > >>>
> > > > >>> > Disable the pool cleaner
> > > > >>> >
> > > > >>> > timeBetweenEvictionRunsMillis=0
> > > > >>> >
> > > > >>> >
> > > > >>> >
> > > > >>>
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Filip Hanik <fi...@hanik.com>.
Robert, kindly let us know if disabling the pool cleaner does resolve your
dead lock
Filip
On Fri, Jan 30, 2015 at 12:25 PM, Robert Anderson <ra...@gmail.com>
wrote:
> Great, Filip!
>
> "Returns true if the pool sweeper is enabled for the connection pool. The
> pool sweeper is enabled if any settings that require async intervention in
> the pool are turned on boolean result =
> getTimeBetweenEvictionRunsMillis()>0; result = result &&
> (isRemoveAbandoned() && getRemoveAbandonedTimeout()>0); result = result ||
> (isTestWhileIdle() && getValidationQuery()!=null); return result;" [1]
>
> Best regards.
>
>
> [1]
>
> https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/tomcat/jdbc/pool/PoolConfiguration.html#isPoolSweeperEnabled()
>
> 2015-01-30 16:13 GMT-03:00 Filip Hanik <fi...@hanik.com>:
>
> > Are you seeing that message, cause it seems to be a defensive check, but
> > wouldn't happen due to
> >
> > 509 public void initializePoolCleaner(PoolConfiguration properties) { 510
> > //if
> > the evictor thread is supposed to run, start it now 511 if (properties.
> > isPoolSweeperEnabled()) { 512 poolCleaner = new PoolCleaner(this,
> > properties
> > .getTimeBetweenEvictionRunsMillis()); 513 poolCleaner.start(); 514 }
> //end
> > if 515 }
> >
> > On Fri, Jan 30, 2015 at 12:05 PM, Robert Anderson <ra...@gmail.com>
> > wrote:
> >
> > > Filip,
> > >
> > > timeBetweenEvictionRunsMillis=0 does not disable PoolCleaner [1].
> > >
> >
> >
> >
> > >
> > > if (sleepTime <= 0) {
> > > log.warn("Database connection pool evicter thread
> > > interval is set to 0, defaulting to 30 seconds");
> > > this.sleepTime = 1000 * 30;
> > > } else if (sleepTime < 1000) {
> > > log.warn("Database connection pool evicter thread
> > > interval is set to lower than 1 second.");
> > > }
> > >
> >
> >
> >
> > >
> > >
> > > [1]
> > >
> >
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
> > >
> > >
> > > 2015-01-30 15:17 GMT-03:00 Robert Anderson <ra...@gmail.com>:
> > >
> > > > Sorry,
> > > >
> > > > [1] https://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
> > > >
> > > > 2015-01-30 15:15 GMT-03:00 Robert Anderson <ra...@gmail.com>:
> > > >
> > > > Filip,
> > > >>
> > > >> however, disabling the pool cleaner it should yield better results.
> > > >>
> > > >> The documention[1] says:
> > > >>
> > > >> "This value should not be set under 1 second"
> > > >>
> > > >> Isn't true?
> > > >>
> > > >>
> > > >>
> > > >> 2015-01-30 15:07 GMT-03:00 Filip Hanik <fi...@hanik.com>:
> > > >>
> > > >> Looking at the locks that are involved in the dead lock, it's all in
> > the
> > > >>> intersys traces. Furthermore, it seems as intersys may already be
> > doing
> > > >>> pooling inside the driver. If that is the case, you have two
> options
> > > >>>
> > > >>> 1. disable pooling in intersys OR
> > > >>> 2. don't use tomcat's jdbc pool since intersys already does pooling
> > > >>>
> > > >>> however, disabling the pool cleaner it should yield better results.
> > > >>>
> > > >>> On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik <fi...@hanik.com>
> > wrote:
> > > >>>
> > > >>> > Disable the pool cleaner
> > > >>> >
> > > >>> > timeBetweenEvictionRunsMillis=0
> > > >>> >
> > > >>> >
> > > >>> >
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Robert Anderson <ra...@gmail.com>.
Great, Filip!
"Returns true if the pool sweeper is enabled for the connection pool. The
pool sweeper is enabled if any settings that require async intervention in
the pool are turned on boolean result =
getTimeBetweenEvictionRunsMillis()>0; result = result &&
(isRemoveAbandoned() && getRemoveAbandonedTimeout()>0); result = result ||
(isTestWhileIdle() && getValidationQuery()!=null); return result;" [1]
Best regards.
[1]
https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/tomcat/jdbc/pool/PoolConfiguration.html#isPoolSweeperEnabled()
2015-01-30 16:13 GMT-03:00 Filip Hanik <fi...@hanik.com>:
> Are you seeing that message, cause it seems to be a defensive check, but
> wouldn't happen due to
>
> 509 public void initializePoolCleaner(PoolConfiguration properties) { 510
> //if
> the evictor thread is supposed to run, start it now 511 if (properties.
> isPoolSweeperEnabled()) { 512 poolCleaner = new PoolCleaner(this,
> properties
> .getTimeBetweenEvictionRunsMillis()); 513 poolCleaner.start(); 514 } //end
> if 515 }
>
> On Fri, Jan 30, 2015 at 12:05 PM, Robert Anderson <ra...@gmail.com>
> wrote:
>
> > Filip,
> >
> > timeBetweenEvictionRunsMillis=0 does not disable PoolCleaner [1].
> >
>
>
>
> >
> > if (sleepTime <= 0) {
> > log.warn("Database connection pool evicter thread
> > interval is set to 0, defaulting to 30 seconds");
> > this.sleepTime = 1000 * 30;
> > } else if (sleepTime < 1000) {
> > log.warn("Database connection pool evicter thread
> > interval is set to lower than 1 second.");
> > }
> >
>
>
>
> >
> >
> > [1]
> >
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
> >
> >
> > 2015-01-30 15:17 GMT-03:00 Robert Anderson <ra...@gmail.com>:
> >
> > > Sorry,
> > >
> > > [1] https://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
> > >
> > > 2015-01-30 15:15 GMT-03:00 Robert Anderson <ra...@gmail.com>:
> > >
> > > Filip,
> > >>
> > >> however, disabling the pool cleaner it should yield better results.
> > >>
> > >> The documention[1] says:
> > >>
> > >> "This value should not be set under 1 second"
> > >>
> > >> Isn't true?
> > >>
> > >>
> > >>
> > >> 2015-01-30 15:07 GMT-03:00 Filip Hanik <fi...@hanik.com>:
> > >>
> > >> Looking at the locks that are involved in the dead lock, it's all in
> the
> > >>> intersys traces. Furthermore, it seems as intersys may already be
> doing
> > >>> pooling inside the driver. If that is the case, you have two options
> > >>>
> > >>> 1. disable pooling in intersys OR
> > >>> 2. don't use tomcat's jdbc pool since intersys already does pooling
> > >>>
> > >>> however, disabling the pool cleaner it should yield better results.
> > >>>
> > >>> On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik <fi...@hanik.com>
> wrote:
> > >>>
> > >>> > Disable the pool cleaner
> > >>> >
> > >>> > timeBetweenEvictionRunsMillis=0
> > >>> >
> > >>> >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Filip Hanik <fi...@hanik.com>.
Are you seeing that message, cause it seems to be a defensive check, but
wouldn't happen due to
509 public void initializePoolCleaner(PoolConfiguration properties) { 510 //if
the evictor thread is supposed to run, start it now 511 if (properties.
isPoolSweeperEnabled()) { 512 poolCleaner = new PoolCleaner(this, properties
.getTimeBetweenEvictionRunsMillis()); 513 poolCleaner.start(); 514 } //end
if 515 }
On Fri, Jan 30, 2015 at 12:05 PM, Robert Anderson <ra...@gmail.com>
wrote:
> Filip,
>
> timeBetweenEvictionRunsMillis=0 does not disable PoolCleaner [1].
>
>
> if (sleepTime <= 0) {
> log.warn("Database connection pool evicter thread
> interval is set to 0, defaulting to 30 seconds");
> this.sleepTime = 1000 * 30;
> } else if (sleepTime < 1000) {
> log.warn("Database connection pool evicter thread
> interval is set to lower than 1 second.");
> }
>
>
>
> [1]
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
>
>
> 2015-01-30 15:17 GMT-03:00 Robert Anderson <ra...@gmail.com>:
>
> > Sorry,
> >
> > [1] https://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
> >
> > 2015-01-30 15:15 GMT-03:00 Robert Anderson <ra...@gmail.com>:
> >
> > Filip,
> >>
> >> however, disabling the pool cleaner it should yield better results.
> >>
> >> The documention[1] says:
> >>
> >> "This value should not be set under 1 second"
> >>
> >> Isn't true?
> >>
> >>
> >>
> >> 2015-01-30 15:07 GMT-03:00 Filip Hanik <fi...@hanik.com>:
> >>
> >> Looking at the locks that are involved in the dead lock, it's all in the
> >>> intersys traces. Furthermore, it seems as intersys may already be doing
> >>> pooling inside the driver. If that is the case, you have two options
> >>>
> >>> 1. disable pooling in intersys OR
> >>> 2. don't use tomcat's jdbc pool since intersys already does pooling
> >>>
> >>> however, disabling the pool cleaner it should yield better results.
> >>>
> >>> On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik <fi...@hanik.com> wrote:
> >>>
> >>> > Disable the pool cleaner
> >>> >
> >>> > timeBetweenEvictionRunsMillis=0
> >>> >
> >>> >
> >>> >
> >>>
> >>
> >>
> >
>
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Robert Anderson <ra...@gmail.com>.
Filip,
timeBetweenEvictionRunsMillis=0 does not disable PoolCleaner [1].
if (sleepTime <= 0) {
log.warn("Database connection pool evicter thread
interval is set to 0, defaulting to 30 seconds");
this.sleepTime = 1000 * 30;
} else if (sleepTime < 1000) {
log.warn("Database connection pool evicter thread
interval is set to lower than 1 second.");
}
[1]http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
2015-01-30 15:17 GMT-03:00 Robert Anderson <ra...@gmail.com>:
> Sorry,
>
> [1] https://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
>
> 2015-01-30 15:15 GMT-03:00 Robert Anderson <ra...@gmail.com>:
>
> Filip,
>>
>> however, disabling the pool cleaner it should yield better results.
>>
>> The documention[1] says:
>>
>> "This value should not be set under 1 second"
>>
>> Isn't true?
>>
>>
>>
>> 2015-01-30 15:07 GMT-03:00 Filip Hanik <fi...@hanik.com>:
>>
>> Looking at the locks that are involved in the dead lock, it's all in the
>>> intersys traces. Furthermore, it seems as intersys may already be doing
>>> pooling inside the driver. If that is the case, you have two options
>>>
>>> 1. disable pooling in intersys OR
>>> 2. don't use tomcat's jdbc pool since intersys already does pooling
>>>
>>> however, disabling the pool cleaner it should yield better results.
>>>
>>> On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik <fi...@hanik.com> wrote:
>>>
>>> > Disable the pool cleaner
>>> >
>>> > timeBetweenEvictionRunsMillis=0
>>> >
>>> >
>>> >
>>>
>>
>>
>
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Filip Hanik <fi...@hanik.com>.
Robert, it should say, if you set a positive value, the value should not be
less than 1000ms. Otherwise you are hammering the system with eviction
checks.
Setting the value to 0, disables the check all together. There are other
ways to disable the same check by setting other flags,
918 @Override 919 public boolean isPoolSweeperEnabled() { 920 boolean timer
= getTimeBetweenEvictionRunsMillis()>0; 921 boolean result = timer && (
isRemoveAbandoned() && getRemoveAbandonedTimeout()>0); 922 result = result
|| (timer && getSuspectTimeout()>0); 923 result = result || (timer &&
isTestWhileIdle() && getValidationQuery()!=null); 924 result = result || (
timer && getMinEvictableIdleTimeMillis()>0); 925 return result; 926 }
On Fri, Jan 30, 2015 at 11:17 AM, Robert Anderson <ra...@gmail.com>
wrote:
> Sorry,
>
> [1] https://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
>
> 2015-01-30 15:15 GMT-03:00 Robert Anderson <ra...@gmail.com>:
>
> > Filip,
> >
> > however, disabling the pool cleaner it should yield better results.
> >
> > The documention[1] says:
> >
> > "This value should not be set under 1 second"
> >
> > Isn't true?
> >
> >
> >
> > 2015-01-30 15:07 GMT-03:00 Filip Hanik <fi...@hanik.com>:
> >
> > Looking at the locks that are involved in the dead lock, it's all in the
> >> intersys traces. Furthermore, it seems as intersys may already be doing
> >> pooling inside the driver. If that is the case, you have two options
> >>
> >> 1. disable pooling in intersys OR
> >> 2. don't use tomcat's jdbc pool since intersys already does pooling
> >>
> >> however, disabling the pool cleaner it should yield better results.
> >>
> >> On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik <fi...@hanik.com> wrote:
> >>
> >> > Disable the pool cleaner
> >> >
> >> > timeBetweenEvictionRunsMillis=0
> >> >
> >> >
> >> >
> >>
> >
> >
>
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Robert Anderson <ra...@gmail.com>.
Sorry,
[1] https://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
2015-01-30 15:15 GMT-03:00 Robert Anderson <ra...@gmail.com>:
> Filip,
>
> however, disabling the pool cleaner it should yield better results.
>
> The documention[1] says:
>
> "This value should not be set under 1 second"
>
> Isn't true?
>
>
>
> 2015-01-30 15:07 GMT-03:00 Filip Hanik <fi...@hanik.com>:
>
> Looking at the locks that are involved in the dead lock, it's all in the
>> intersys traces. Furthermore, it seems as intersys may already be doing
>> pooling inside the driver. If that is the case, you have two options
>>
>> 1. disable pooling in intersys OR
>> 2. don't use tomcat's jdbc pool since intersys already does pooling
>>
>> however, disabling the pool cleaner it should yield better results.
>>
>> On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik <fi...@hanik.com> wrote:
>>
>> > Disable the pool cleaner
>> >
>> > timeBetweenEvictionRunsMillis=0
>> >
>> >
>> >
>>
>
>
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Robert Anderson <ra...@gmail.com>.
Filip,
however, disabling the pool cleaner it should yield better results.
The documention[1] says:
"This value should not be set under 1 second"
Isn't true?
2015-01-30 15:07 GMT-03:00 Filip Hanik <fi...@hanik.com>:
> Looking at the locks that are involved in the dead lock, it's all in the
> intersys traces. Furthermore, it seems as intersys may already be doing
> pooling inside the driver. If that is the case, you have two options
>
> 1. disable pooling in intersys OR
> 2. don't use tomcat's jdbc pool since intersys already does pooling
>
> however, disabling the pool cleaner it should yield better results.
>
> On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik <fi...@hanik.com> wrote:
>
> > Disable the pool cleaner
> >
> > timeBetweenEvictionRunsMillis=0
> >
> >
> >
>
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Filip Hanik <fi...@hanik.com>.
Looking at the locks that are involved in the dead lock, it's all in the
intersys traces. Furthermore, it seems as intersys may already be doing
pooling inside the driver. If that is the case, you have two options
1. disable pooling in intersys OR
2. don't use tomcat's jdbc pool since intersys already does pooling
however, disabling the pool cleaner it should yield better results.
On Fri, Jan 30, 2015 at 11:02 AM, Filip Hanik <fi...@hanik.com> wrote:
> Disable the pool cleaner
>
> timeBetweenEvictionRunsMillis=0
>
>
>
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Filip Hanik <fi...@hanik.com>.
Disable the pool cleaner
timeBetweenEvictionRunsMillis=0
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Robert Anderson <ra...@gmail.com>.
Could you post a full stacktrace, or threaddump?
"ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 -
DB:DATASOURCE(java:/comp/env/jdbc/cacheapp)" daemon prio=10
tid=0x0000000013bb0000 nid=0x7a6d waiting for monitor entry
[0x000000005125b000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.intersys.jdbc.CacheConnection.close(CacheConnection.java:552)
- waiting to lock <0x000000071ba001d0> (a
com.intersys.jdbc.CacheConnection)
at
com.intersys.jdbc.InStream.invalidMessageReceived(InStream.java:234)
- locked <0x000000071ba094c0> (a com.intersys.jdbc.InStream)
at com.intersys.jdbc.InStream.checkHeader(InStream.java:104)
- eliminated <0x000000071ba094c0> (a com.intersys.jdbc.InStream)
at com.intersys.jdbc.InStream.readHeader(InStream.java:148)
- locked <0x000000071ba094c0> (a com.intersys.jdbc.InStream)
at
com.intersys.jdbc.CacheStatement.sendDirectQueryRequest(CacheStatement.java:551)
- locked <0x000000071ba007f0> (a
com.intersys.jdbc.CacheConnection$MessageCount)
- locked <0x000000071ba00150> (a com.intersys.jdbc.CacheStatement)
at com.intersys.jdbc.CacheStatement.Query(CacheStatement.java:486)
- locked <0x000000071ba00150> (a com.intersys.jdbc.CacheStatement)
at
com.intersys.jdbc.CacheStatement.executeQuery(CacheStatement.java:418)
- locked <0x000000071ba00150> (a com.intersys.jdbc.CacheStatement)
at
br.com.itx.database.impl.ConnectionSql.execute(ConnectionSql.java:246)
at
br.com.itx.integration.DatabaseHandler.execute(DatabaseHandler.java:274)
at
br.com.itx.integration.DatabaseHandler.execute(DatabaseHandler.java:163)
at
br.com.itx.engine.CoreObjectElement.execute(CoreObjectElement.java:88)
at
br.com.itx.component.taglib.ExecuteCore.doStartTag(ExecuteCore.java:98)
at
org.apache.jsp.portaladv.main_005fpre_jsp._jspx_meth_w_005fexecuteCore_005f41(main_005fpre_jsp.java:2858)
at
org.apache.jsp.portaladv.main_005fpre_jsp._jspService(main_005fpre_jsp.java:718)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:748)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:604)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:543)
at br.com.itx.engine.Execute.doJsp(Execute.java:476)
at br.com.itx.engine.Execute.doPost(Execute.java:425)
- locked <0x000000071ba34398> (a java.lang.Object)
at br.com.itx.engine.Execute.doGet(Execute.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:620)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
at
com.googlecode.psiprobe.Tomcat70AgentValve.invoke(Tomcat70AgentValve.java:38)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at
org.apache.catalina.valves.StuckThreadDetectionValve.invoke(StuckThreadDetectionValve.java:221)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:421)
at
org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:188)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
at
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2466)
at
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2455)
- locked <0x000000071b7df138> (a
org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
"PoolCleaner[1070846187:1422601344160]" daemon prio=10
tid=0x0000000013306800 nid=0x71e0 waiting for monitor entry
[0x00000000417fd000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.intersys.jdbc.CacheConnection.close(CacheConnection.java:566)
- waiting to lock <0x000000071ba007f0> (a
com.intersys.jdbc.CacheConnection$MessageCount)
- locked <0x000000071ba001d0> (a com.intersys.jdbc.CacheConnection)
at
org.apache.tomcat.jdbc.pool.PooledConnection.disconnect(PooledConnection.java:331)
at
org.apache.tomcat.jdbc.pool.PooledConnection.release(PooledConnection.java:495)
at
org.apache.tomcat.jdbc.pool.ConnectionPool.release(ConnectionPool.java:582)
at
org.apache.tomcat.jdbc.pool.ConnectionPool.abandon(ConnectionPool.java:541)
at
org.apache.tomcat.jdbc.pool.ConnectionPool.checkAbandoned(ConnectionPool.java:956)
at
org.apache.tomcat.jdbc.pool.ConnectionPool$PoolCleaner.run(ConnectionPool.java:1345)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Are there any exceptions logged before?
There are many exceptions every day (invalid parameters, syntax error, ...)
2015-01-30 14:33 GMT-03:00 Felix Schumacher <
felix.schumacher@internetallee.de>:
> Am 30.01.2015 um 18:19 schrieb Robert Anderson:
>
>> Every day we are getting deadlocks like that:
>>
>> Found one Java-level deadlock:
>> =============================
>> "ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 -
>> DB:DATASOURCE(java:/comp/env/jdbc/cacheapp)":
>> waiting to lock monitor 0x000000001504e6d8 (object 0x000000071ba001d0,
>> a
>> com.intersys.jdbc.CacheConnection),
>> which is held by "PoolCleaner[1070846187:1422601344160]"
>> "PoolCleaner[1070846187:1422601344160]":
>> waiting to lock monitor 0x0000000012ce77e8 (object 0x000000071ba007f0,
>> a
>> com.intersys.jdbc.CacheConnection$MessageCount),
>> which is held by "ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 -
>> DB:DATASOURCE(java:/comp/env/jdbc/cacheapp)"
>>
> Could you post a full stacktrace, or threaddump?
>
> Are there any exceptions logged before?
>
> Regards
> Felix
>
>>
>>
>> Are there anything that we can do to avoid it?
>>
>>
>> Server version: Apache Tomcat/7.0.57
>> Server built: Nov 3 2014 08:39:16 UTC
>> Server number: 7.0.57.0
>> OS Name: Linux
>> OS Version: 2.6.18-194.17.1.el5
>> Architecture: amd64
>> JVM Version: 1.7.0_71-b14
>> JVM Vendor: Oracle Corporation
>>
>>
>> Datasource definition:
>>
>> <Resource name="jdbc/cacheapp" auth="Container"
>> type="javax.sql.DataSource"
>> removeAbandoned="true" removeAbandonedTimeout="300"
>> maxActive="120" maxIdle="20"
>> minIdle="1"
>> maxWait="10000"
>> validationQuery="select 1"
>> testOnBorrow="true"
>> validationInterval="0"
>> fairQueue="false"
>>
>> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
>> alternateUsernameAllowed="true"
>> username="user" password="password"
>> driverClassName="com.intersys.jdbc.CacheDriver"
>>
>> url="jdbc:Cache://myserver:1972/Namespace"/>
>>
>>
>> Thanks in advance.
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: tomcat-jdbc PoolCleaner deadlock
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 30.01.2015 um 18:19 schrieb Robert Anderson:
> Every day we are getting deadlocks like that:
>
> Found one Java-level deadlock:
> =============================
> "ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 -
> DB:DATASOURCE(java:/comp/env/jdbc/cacheapp)":
> waiting to lock monitor 0x000000001504e6d8 (object 0x000000071ba001d0, a
> com.intersys.jdbc.CacheConnection),
> which is held by "PoolCleaner[1070846187:1422601344160]"
> "PoolCleaner[1070846187:1422601344160]":
> waiting to lock monitor 0x0000000012ce77e8 (object 0x000000071ba007f0, a
> com.intersys.jdbc.CacheConnection$MessageCount),
> which is held by "ajp-apr-8009-exec-13 ^ 30/01/2015 - 09:39:58 -
> DB:DATASOURCE(java:/comp/env/jdbc/cacheapp)"
Could you post a full stacktrace, or threaddump?
Are there any exceptions logged before?
Regards
Felix
>
>
> Are there anything that we can do to avoid it?
>
>
> Server version: Apache Tomcat/7.0.57
> Server built: Nov 3 2014 08:39:16 UTC
> Server number: 7.0.57.0
> OS Name: Linux
> OS Version: 2.6.18-194.17.1.el5
> Architecture: amd64
> JVM Version: 1.7.0_71-b14
> JVM Vendor: Oracle Corporation
>
>
> Datasource definition:
>
> <Resource name="jdbc/cacheapp" auth="Container" type="javax.sql.DataSource"
> removeAbandoned="true" removeAbandonedTimeout="300"
> maxActive="120" maxIdle="20" minIdle="1"
> maxWait="10000"
> validationQuery="select 1"
> testOnBorrow="true"
> validationInterval="0"
> fairQueue="false"
>
> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
> alternateUsernameAllowed="true"
> username="user" password="password"
> driverClassName="com.intersys.jdbc.CacheDriver"
>
> url="jdbc:Cache://myserver:1972/Namespace"/>
>
>
> Thanks in advance.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org