https://bz.apache.org/bugzilla/show_bug.cgi?id=59334

            Bug ID: 59334
           Summary: .NET Application Pools requests hang because
                    Jakarta/Tomcat uses a Named Mutex that is currently
                    owned by a different process
           Product: Tomcat 7
           Version: 7.0.42
          Hardware: PC
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Integration
          Assignee: dev@tomcat.apache.org
          Reporter: murilo.v.andre...@gmail.com

We have a server that hosts three .NET v4.0 applications (each one in their own
app pool) and another application that is hosted in Jakarta/Tomcat 7, which
goes through IIS for authentication, and is forwarded to
Jakarta/Tomcat(isapi_redirect.dll)

We've started noticing that every now and then one of the .NET application
pools was (randomly) hanging, requiring the support team to log on to the
server and recycle it. Initially, we thought that the problem was related to
the applications themselves, maybe memory leaks.

Further investigations confirmed that the applications pools were hanging
because Jakarta was using Named Mutexes, and sometimes ones that were currently
owned by different processes (one of the other App Pools). And since Named
Mutexes are shared across processes, any process trying to use it would be
blocked until owner process releases the Mutex.

Long story short, we've confirmed that the hangs happen because Tomcat is
leaking mutexes and not releasing them back to the other applications.

This seems to be very similar to the problem described here in this thread: 
https://bz.apache.org/bugzilla/show_bug.cgi?id=58813#c0

But no one has replied to it.

Also, the change log
(https://tomcat.apache.org/connectors-doc/miscellaneous/changelog.html) shows a
fix between versions "1.2.35 and 1.2.36" stating "Fix dead-lock caused by not
releasing mutex on close. (mturk)" which seems to be exactly what we're facing,
but either that was another issue, or the fix did not work.

Are there any plans to have this fixed in a future release?

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to