Details

      Description

      Hi,

      since some time we are experiencing a deadlock in the mordred connection pool. It seems that this deadlock occurs only when sql queries take very long.

      I submitted a patch to the james developer mailing list.

      excerpt from a typical thread dump:

      Found one Java-level deadlock:
      =============================
      "default Worker #4":
      waiting to lock monitor 0x8856f1c (object 0x44b4d568, a org.apache.james.util.mordred.PoolConnEntry),
      which is held by "Thread-3"
      "Thread-3":
      waiting to lock monitor 0x8856ffc (object 0x44b40138, a java.util.Vector),
      which is held by "default Worker #4"

      Java stack information for the threads listed above: ===================================================
      "default Worker #4":
      at
      org.apache.james.util.mordred.PoolConnEntry.lock(PoolConnEntry.java:110)

      • waiting to lock <0x44b4d568> (a
        org.apache.james.util.mordred.PoolConnEntry)
        at org.apache.james.util.mordred.JdbcDataSource.getConnection(JdbcDataSource.ja
        va:178)
      • locked <0x44b40138> (a java.util.Vector)
        at org.apache.james.mailrepository.JDBCSpoolRepository.loadPendingMessages(JDBC
        SpoolRepository.java:281)
      • locked <0x44b5f218> (a java.util.LinkedList)
        at org.apache.james.mailrepository.JDBCSpoolRepository.getNextPendingMessage(JD
        BCSpoolRepository.java:256)
      • locked <0x44b5f218> (a java.util.LinkedList)
        at org.apache.james.mailrepository.JDBCSpoolRepository.accept(JDBCSpoolReposito
        ry.java:154)
        at
        org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:350)
        at org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.execute(Executabl
        eRunnable.java:47)
        at org.apache.avalon.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:8
        0)
      • locked <0x44ba24b0> (a
        org.apache.avalon.excalibur.thread.impl.WorkerThread)
        "Thread-3":
        at java.util.Vector.removeElement(Vector.java:605)
      • waiting to lock <0x44b40138> (a java.util.Vector)
        at org.apache.james.util.mordred.JdbcDataSource.finalizeEntry(JdbcDataSource.ja
        va:579)
      • locked <0x44b400b0> (a
        org.apache.james.util.mordred.JdbcDataSource)
        at
        org.apache.james.util.mordred.JdbcDataSource.run(JdbcDataSource.java:452)
      • locked <0x44b4d568> (a
        org.apache.james.util.mordred.PoolConnEntry)
        at java.lang.Thread.run(Thread.java:536)

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        23h 42m 1 Noel J. Bergman 14/Apr/04 17:41
        Resolved Resolved Closed Closed
        52d 2h 54m 1 Vincenzo Gianferrari Pini 05/Jun/04 20:35
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12565829 ] jira [ 12581957 ]
        Mark Thomas made changes -
        Workflow jira [ 31005 ] Default workflow, editable Closed status [ 12565829 ]
        Vincenzo Gianferrari Pini made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Noel J. Bergman made changes -
        Field Original Value New Value
        Fix Version/s 2.2.0a19 [ 10689 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Noel J. Bergman added a comment -

        Patch applied based upon Marcus Labib's contribution. Enforces synchronized access to the pool. Also added code based upon his patch to first just log overly long-lived connections, and then close them at a later time. Not sure it is needed, but if the code is ever exercised, it should provide some data on "stuck" connections.

        It should be noted that mordred is considered deprecated in favor of DBCP.

        Show
        Noel J. Bergman added a comment - Patch applied based upon Marcus Labib's contribution. Enforces synchronized access to the pool. Also added code based upon his patch to first just log overly long-lived connections, and then close them at a later time. Not sure it is needed, but if the code is ever exercised, it should provide some data on "stuck" connections. It should be noted that mordred is considered deprecated in favor of DBCP.
        Marcus Labib created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            Marcus Labib
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development