Replace IndexedDB connection pool thread management with task queues on top of a thread pool
Categories
(Core :: Storage: IndexedDB, task)
Tracking
()
People
(Reporter: jstutte, Assigned: jjalkanen)
References
(Blocks 12 open bugs)
Details
Attachments
(9 files, 15 obsolete files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
be1cda4f-0d00-45f0-8802-629180220919 shows a case with IndexedDB #1,SHDRCV
being stuck on a SpinEventLoopUntil
:
0 ZwWaitForAlertByThreadId
1 RtlSleepConditionVariableSRW
2 SleepConditionVariableSRW
3 mozilla::detail::ConditionVariableImpl::wait(mozilla::detail::MutexImpl&)
4 mozilla::OffTheBooksCondVar::Wait()
4 mozilla::ThreadEventQueue::GetEvent(bool, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>*)
4 nsThread::ProcessNextEvent(bool, bool*)
5 NS_ProcessNextEvent(nsIThread*, bool)
6 mozilla::SpinEventLoopUntil(nsTSubstring<char> const&, mozilla::dom::indexedDB::(anonymous namespace)::ConnectionPool::ThreadRunnable::Run::<lambda_87>&&, nsIThread*)
6 mozilla::dom::indexedDB::(anonymous namespace)::ConnectionPool::ThreadRunnable::Run()
7 nsThread::ProcessNextEvent(bool, bool*)
8 NS_ProcessNextEvent(nsIThread*, bool)
8 mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*)
This indicates a possible misalignment between gLiveDatabaseHashtable->Count()
being zero during QuotaManager
shutdown (which was not blocked) and the ConnectionPool
state, as it needs to explicitly call ConnectionPool::ShutdownThread
for all its threads to unblock that SpinEventLoopUntil
we see blocking here.
Reporter | ||
Comment 1•2 years ago
|
||
I am also wondering if with bug 1121282 fixed we could simplify this whole thing by not managing our own thread pool at all but just using a normal nsThreadPool
? IIUC the main purpose of the ConnectionPool
's thread handling is to guarantee to use a connection only on the same thread it was created on ?
Comment 2•2 years ago
|
||
I think with that relaxed we can actually go a step further and just use an NS_CreateBackgroundTaskQueue-created queue for each connection "thread" and bypass the need for a custom pool at all, noting that ConnectionPool also provides the mechanism for tracking when a connection is idle and triggers closing of the database because it's idle to limit resource usage. Since file descriptors continue to not be infinite, it does seem appropriate to continue to keep the idle mechanism, and there's a bunch of related logic that would probably get renamed/refactored, like ConnectionPool::ScheduleTransaction.
Comment 3•2 years ago
|
||
As to comment 0 and be1cda4f-0d00-45f0-8802-629180220919, yeah it seems like there's a race with thread creation and shutdown or something like that, because IPDL Background and the QM I/O thread are definitely already gone, which suggests the thread was created very late.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 4•2 years ago
|
||
Assignee | ||
Comment 5•2 years ago
|
||
Depends on D160471
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 6•2 years ago
|
||
Comment 8•2 years ago
|
||
bugherder |
Reporter | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 9•2 years ago
|
||
Depends on D160472
Assignee | ||
Comment 10•2 years ago
|
||
Depends on D165984
Assignee | ||
Comment 11•1 year ago
|
||
Depends on D165984
Assignee | ||
Comment 12•1 year ago
|
||
Depends on D179089
Updated•1 year ago
|
Comment 13•1 year ago
|
||
Comment on attachment 9335903 [details]
Bug 1791767 - Replace single element array with a pointer class. r=#dom-storage
Revision D179090 was moved to bug 1837369. Setting attachment 9335903 [details] to obsolete.
Comment 14•1 year ago
|
||
Is this still a "leave-open" bug? If so, why?
Assignee | ||
Comment 15•1 year ago
|
||
Originally, the leave-open tag was added because we needed an extension to a utility in a different component as a prerequisite for other work related to this bug, and did not want the automation to close the ticket after the first item landed.
Now, the most relevant patches are still in review but we probably don't want to land (merge) them one by one so from that point of view, we don't need the leave-open tag anymore. After the patches are in, the code path which is relevant for the hang has been removed, so keeping the leave-open tag for monitoring purposes also won't be purposeful.
Updated•1 year ago
|
Comment 16•1 year ago
|
||
(In reply to Jari Jalkanen from comment #15)
Originally, the leave-open tag was added because we needed an extension to a utility in a different component as a prerequisite for other work related to this bug, and did not want the automation to close the ticket after the first item landed.
Now, the most relevant patches are still in review but we probably don't want to land (merge) them one by one so from that point of view, we don't need the leave-open tag anymore. After the patches are in, the code path which is relevant for the hang has been removed, so keeping the leave-open tag for monitoring purposes also won't be purposeful.
So, this is all still pending a review?
Comment 18•1 year ago
|
||
Comment 19•1 year ago
•
|
||
Backed out as requested, backout link: https://hg.mozilla.org/integration/autoland/rev/9b1e2f9d999edf3ac20bd828cccf22d9553018ca
Comment 20•1 year ago
|
||
Updated•1 year ago
|
Assignee | ||
Comment 21•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Assignee | ||
Comment 22•1 year ago
|
||
Depends on D190279
Assignee | ||
Comment 23•1 year ago
|
||
Depends on D190598
Assignee | ||
Comment 24•1 year ago
|
||
Depends on D190599
Assignee | ||
Comment 25•1 year ago
|
||
CachingDatabaseConnection relies on a global macro to toggle thread
ownership checks. The checks do not work with thread pool event targets
and by this change we ensure that the global macro users are not
impacted by such event target changes.
Depends on D190600
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 26•1 year ago
|
||
Comment 27•1 year ago
|
||
bugherder |
Comment 28•1 year ago
|
||
Comment 29•1 year ago
|
||
bugherder |
Comment 30•1 year ago
|
||
Comment 31•1 year ago
|
||
bugherder |
Comment 32•1 year ago
|
||
Comment on attachment 9357660 [details]
Bug 1791767 - Remove IDB transaction scheduling queue. r=#dom-storage
Revision D190600 was moved to bug 1791766. Setting attachment 9357660 [details] to obsolete.
Assignee | ||
Comment 33•1 year ago
|
||
Depends on D190599
Assignee | ||
Comment 34•1 year ago
|
||
Depends on D165984
Assignee | ||
Comment 35•1 year ago
|
||
Depends on D190600
Updated•1 year ago
|
Assignee | ||
Comment 36•1 year ago
|
||
Depends on D190599
Assignee | ||
Comment 37•1 year ago
|
||
Depends on D165984
Assignee | ||
Comment 38•1 year ago
|
||
Depends on D190600
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 39•1 year ago
|
||
Comment 40•1 year ago
|
||
bugherder |
Comment 41•1 year ago
|
||
Assignee | ||
Comment 42•1 year ago
|
||
Assignee | ||
Comment 43•1 year ago
|
||
Depends on D191451
Assignee | ||
Comment 44•1 year ago
|
||
Depends on D191452
Comment 45•1 year ago
|
||
bugherder |
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Assignee | ||
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•7 months ago
|
Assignee | ||
Comment 46•7 months ago
|
||
Updated•7 months ago
|
Updated•7 months ago
|
Comment 47•7 months ago
|
||
Comment 48•7 months ago
|
||
Comment 49•7 months ago
|
||
Comment 50•7 months ago
|
||
bugherder |
Assignee | ||
Updated•6 months ago
|
Comment 51•6 months ago
|
||
Comment 52•6 months ago
|
||
Backed out for causing build bustages in ActorsParent.cpp
- Backout link
- Push with failures
- Failure Log
- Failure line: /builds/worker/checkouts/gecko/dom/indexedDB/ActorsParent.cpp:8824:1: error: 'mozilla::dom::indexedDB::{anonymous}::ConnectionPool::IdleThreadInfo::~IdleThreadInfo()' defined but not used [-Werror=unused-function]
Updated•6 months ago
|
Comment 53•6 months ago
|
||
Updated•6 months ago
|
Comment 54•6 months ago
|
||
bugherder |
Comment 55•6 months ago
|
||
Assignee | ||
Comment 56•6 months ago
|
||
The main patch replacing the custom thread pool with nsThreadPool landed.
Assignee | ||
Comment 57•6 months ago
|
||
After a thorough discussion about performance regression 1891227, the following plan was conceived:
We would like to back out patch https://phabricator.services.mozilla.com/D191296 from beta, to keep the regression from impacting the users, but keep it in nightly and actively work to overcome the regression. There are already some preliminary investigations on nsThreadPool addressing the challenge.
Comment 58•6 months ago
|
||
Comment 59•5 months ago
|
||
Jari, we are nearing the start of the 127 beta cycle and bug 1891227 was not fixed, should we back out D191296 again when we reach beta?
Assignee | ||
Comment 60•5 months ago
|
||
It would be nice if you could back it out once more, thank you! The related fix probably won't quite make it to this cycle.
Reporter | ||
Updated•5 months ago
|
Comment 61•5 months ago
|
||
backout bugherder uplift |
Backed out 1 changesets (bug 1791767) from beta for introducing Bug 1891227
https://hg.mozilla.org/releases/mozilla-beta/rev/1d48046b04e7
Updated•5 months ago
|
Updated•5 months ago
|
Assignee | ||
Comment 62•4 months ago
|
||
The fix to the performance surprise 1891227 landed so there is no longer a reason why this could not ride the trains, once more.
Comment 63•4 months ago
|
||
Comment on attachment 9394936 [details]
Bug 1791767 - Remove unneeded AdjustIdleTimer call; r=#dom-storage
Revision D206588 was moved to bug 1900380. Setting attachment 9394936 [details] to obsolete.
Comment 64•4 months ago
|
||
Comment on attachment 9352049 [details]
Bug 1791767 - Test IDB and OPFS interaction under heavy load; r=#dom-storage
Revision D187686 was moved to bug 1900382. Setting attachment 9352049 [details] to obsolete.
Comment 65•4 months ago
|
||
Set status for 126 and 127 to wontfix since it was backed out on those branches.
Updated•4 months ago
|
Reporter | ||
Comment 66•4 months ago
|
||
Do we need to move some of the open patches to another bug to be able to close this such that the status flags continue to make sense?
Comment 67•4 months ago
|
||
Comment on attachment 9357660 [details]
Bug 1791767 - Remove IDB transaction scheduling queue. r=#dom-storage
Revision D190600 was moved to bug 1903603. Setting attachment 9357660 [details] to obsolete.
Comment 68•4 months ago
|
||
Comment on attachment 9359086 [details]
Bug 1791767 - Drain IDB task queues on shutdown. r=#dom-storage
Revision D191297 was moved to bug 1903607. Setting attachment 9359086 [details] to obsolete.
Comment 69•4 months ago
|
||
Comment on attachment 9359395 [details]
Bug 1791767 - Remove IdleConnectionRunnable class. r=#dom-storage
Revision D191453 was moved to bug 1903614. Setting attachment 9359395 [details] to obsolete.
Comment 70•4 months ago
|
||
Comment on attachment 9359394 [details]
Bug 1791767 - Dispatch IDB idle maintenance with InvokeAsync and promises. r=#dom-storage
Revision D191452 was moved to bug 1903614. Setting attachment 9359394 [details] to obsolete.
Assignee | ||
Comment 71•4 months ago
|
||
The patches which were not strictly required for this ticket were moved to dedicated items.
Comment 72•3 months ago
|
||
All the patches still associated with this bug landed. https://phabricator.services.mozilla.com/D191296 was only backed out of Beta, so it is still fixed for Firefox 128.
Updated•3 months ago
|
Description
•