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 <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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Reply via email to