716172 - Waiting for nsCacheService::Lock on the main thread

Status: RESOLVED DUPLICATE of bug 717761

(Core :: Networking: Cache, defect)

Description

[David Mandelin [:dmandelin]]

Attachment: Instrumentation patch

I'm finding that it's pretty common to spend 3s or so waiting for nsCacheService::Lock on the main thread. This is on Win 7 with the attached patch. 

The strange thing is that it's not obvious that the browser is actually unresponsive during that time, so I might be doing something wrong, or understanding the results wrong.

Comment 1

[David Mandelin [:dmandelin]]

I was just using Zimbra, and when deleting an email, it took extra long (i.e., showing the OS's busy cursor for 1s+), and an "action cache_lock 1600.000" printed out. So I'm pretty sure these can cause serious visible delays.

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Was the busy cursor on the Zimbra UI or the browser chrome.  Zimbra uses sync XHR, which will cause the busy cursor in the content area, so that could be what you're seeing.

Comment 3

[David Mandelin [:dmandelin]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #2)
> Was the busy cursor on the Zimbra UI or the browser chrome.  Zimbra uses
> sync XHR, which will cause the busy cursor in the content area, so that
> could be what you're seeing.

It seems that the busy cursor is in the Zimbra UI (i.e., if I leave the cursor over the title bar, then I don't get a busy cursor) but the browser still locks up.

I'm still getting these pauses after the cache-closing bug got fixed. One I got today looks like this:

event xpcom 204019417.0 5137.0
 47 samples:
    NtWaitForSingleObject
    RtlIntegerToUnicodeString
    PR_Lock
    nsCacheService::Lock
    nsCacheService::OpenCacheEntry
    nsCacheSession::OpenCacheEntry
    nsHttpChannel::DoInvalidateCacheEntry
    nsHttpChannel::MaybeInvalidateCacheEntryForSubsequentGet
    nsHttpChannel::ProcessResponse
    nsHttpChannel::OnStartRequest
    nsInputStreamPump::OnStateStart
    nsInputStreamPump::OnInputStreamReady

Comment 4

[u408661]

We're discussing this in bug 717761