Bug 740628
Summary: | Potential issue in how AsyncTasks run in the task subsystem | ||
---|---|---|---|
Product: | [Retired] Pulp | Reporter: | Jay Dobies <jason.dobies> |
Component: | z_other | Assignee: | Jason Connor <jconnor> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Preethi Thomas <pthomas> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 1.0.0 | CC: | mmccune, skarmark |
Target Milestone: | --- | Keywords: | Triaged |
Target Release: | Sprint 29 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-02-24 20:15:51 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jay Dobies
2011-09-22 17:56:13 UTC
Conversation with jconnor: <jdob> i was talking to jortel about gofer stuffs <linear> ok <jdob> and he mentioned how we have AsyncTask in the task subsystem <jdob> that will wait on the correlated reply from gofer before marking the task as complete <jdob> i was curious what state the task sits in while waiting for that and if it holds up one of the queue threads <jdob> he said it doesnt, but based on my limited understanding of the task queue i'm not sure how the task would reflect as "running" but not be holding up a thread <linear> hmmm <linear> lemme look <jdob> he said he ran it past you, and I'm not really concerned there's an issue so much as I am curious how it's handled <linear> ok, so he's right and he's not <linear> the async task's actual kernel-level thread will exit, more or less, immediately <jdob> right, as soon as gofer acknowledges it got the request and is gonna dispatch it <linear> however, the task sits in a 'running' state, which will count towards the queue's max running quota <linear> so it can block other threads from being fired off <jdob> so 4 of those will lock up pulp solid. <linear> yep <jdob> that's a huge ass problem <jdob> cause he added install to consumer group <jdob> which does one task per consumer <jdob> so you just stopped your pulp server dead in its tracks from doing anything else <linear> until everything is installed, hmmm <jdob> which is really bad in this case since all of the actual work is being done on consumers <jdob> so the pulp server is grossly idle <linear> perhaps we need a new state for tasks, something like: idle <jdob> thats what my gut had expected to see in the task subsystem <linear> that will not blocks other tasks from being launched <jdob> that those tasks changed to something like that We've solved this with the new weighted tasks proposal. the AsyncTasks have a default weight of 0, and therefore don't block tasks behind them while they're running. https://fedorahosted.org/pulp/wiki/WeightedTasks build: 0.238 To test this, kick off a number of AsyncTasks (weight: 0) equal to the [tasking] concurrency_threshold, which defaults to: 4, (consumer package installs, for instance), then kick off a weighted task (repo sync for instance). Notice that the weighted task is able to run right away (state of running or finished in task status) If the weighted task has to wait for the AsyncTasks, this bug fails QA, if it doesn't, it passes. verified [root@preethi ~]# rpm -q pulp pulp-0.0.240-1.fc15.noarch I was able to schedule repo sync & package install at the same time and repo sync ran without waiting for package install to finish. Pulp v1.0 is released Closed Current Release. Pulp v1.0 is released. |