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

        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.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development