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: [email protected]
Reporter: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
