xplanner

Deadlock upon session timeout

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Duplicate
  • Affects Version/s: 0.7
  • Fix Version/s: 0.7
  • Component/s: Overall
  • Labels:
    None
  • JDK version and platform:
    Sun JDK 1.5.0_05 for Linux
  • Database:
    MySQL 4.0.23
  • Application server:
    Tomcat 5.5.9

Description

If you open a session, wait for some time (30-40 minutes) and then click on a link, the link works but in the Tomcat-logs appears something like this:

2005-10-30 08:48:35,325 [Timer-0] WARN async.ThreadPoolAsynchronousRunner - com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@67da00 -- APPARENT DEA
DLOCK!!! Creating emergency threads for unassigned pending tasks!
2005-10-30 08:48:35,325 [Timer-0] WARN async.ThreadPoolAsynchronousRunner - com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@67da00 -- APPARENT DEA
DLOCK!!! Complete Status: [num_managed_threads: 3, num_active: 3; activeTasks: com.mchange.v2.resourcepool.BasicResourcePool$5@44239d (com.mchange.v2.async.ThreadPool
AsynchronousRunner$PoolThread-#1), com.mchange.v2.resourcepool.BasicResourcePool$5@17e1a9b (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0), com.mcha
nge.v2.resourcepool.BasicResourcePool$5@4c123 (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2); pendingTasks: com.mchange.v2.resourcepool.BasicResour
cePool$AcquireTask@23e5f8, com.mchange.v2.resourcepool.BasicResourcePool$5@cf1ca7, com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@1622bd8, com.mchange.v2.r
esourcepool.BasicResourcePool$5@2ca6ee, com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@183838f, com.mchange.v2.resourcepool.BasicResourcePool$5@13244f0, co
m.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@14c07f3, com.mchange.v2.resourcepool.BasicResourcePool$5@9dfac7, com.mchange.v2.resourcepool.BasicResourcePool
$AcquireTask@1bb33a6, com.mchange.v2.resourcepool.BasicResourcePool$5@13be583, com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@1590b7a, com.mchange.v2.c3p0.
stmt.GooGooStatementCache$2@1008189, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@384dfd, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@881d27, com.mchange.v2.c3
p0.stmt.GooGooStatementCache$2@322528, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@25a2be, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@df7a7c, com.mchange.v2.
c3p0.stmt.GooGooStatementCache$2@1e274c6, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@60b3bb, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@b7c991, com.mchange.
v2.c3p0.stmt.GooGooStatementCache$2@127f2b, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@5b1b95, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@17009c0, com.mchan
ge.v2.c3p0.stmt.GooGooStatementCache$2@901e03, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@1a26fdd, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@15e39e2, com.m
change.v2.c3p0.stmt.GooGooStatementCache$3@12a3aac, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@1720e7f, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@115cf42,
com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@da20ab, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@96d9c3, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@1b29bc
4, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@1107f7a, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@214916, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@14
557ef, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@1901cf9, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@5e483d, com.mchange.v2.c3p0.stmt.GooGooStatementCache$
2@1d8dd9b, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@bd1c46, com.mchange.v2.c3p0.stmt.GooGooStatementCache$2@18b4353, com.mchange.v2.c3p0.stmt.GooGooStatementCa
che$2@1f12c12]

Tomcat becomes unresponsible after this and has to be restarted which has a severe impact on all other applications running on the same server.

Issue XPR-151 seems to be caused by this, too.

Issue Links

Activity

Hide
Kurt Huwig added a comment -
The session-timeout is set to 600 seconds (10 minutes) in web.xml:

    <session-config>
        <session-timeout>600</session-timeout>
    </session-config>

It happened after about 29-30 minutes and I was unable to reproduce it after 12 minutes.

This issue happens about twice a week.
Show
Kurt Huwig added a comment - The session-timeout is set to 600 seconds (10 minutes) in web.xml:     <session-config>         <session-timeout>600</session-timeout>     </session-config> It happened after about 29-30 minutes and I was unable to reproduce it after 12 minutes. This issue happens about twice a week.
Hide
Jacques Morel added a comment -
Show
Jacques Morel added a comment - Look at https://sourceforge.net/forum/message.php?msg_id=3419648 for another occurence
Hide
Mateusz Prokopowicz added a comment -
Updating c3p0 to version 0.9.0.2 solved that problem.
The following fix appeared in the version 0.9.0.2:

bg. fixed bug wherein connection-testing on checking occured in a thread holding the pool's lock, leading to pool hangs or deadlocks if a connection hangs.
Show
Mateusz Prokopowicz added a comment - Updating c3p0 to version 0.9.0.2 solved that problem. The following fix appeared in the version 0.9.0.2: bg. fixed bug wherein connection-testing on checking occured in a thread holding the pool's lock, leading to pool hangs or deadlocks if a connection hangs.

People

Vote (1)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: