Closed Bug 927550 Opened 7 years ago Closed 7 years ago
allow an xpcshell test to request longer timeout before it is killed
+++ This bug was initially created as a clone of Bug #794303 Comment 58 +++ In bug 794303 we identified a case where we need to run a long test but it is killed by xpcshell after the standard timeout (seems to be 5 * 60 seconds). See Bug #794303 Comment 68 for the try runs that seem to confirm this problem. In this bug I propose to add infrastructure to xpcshell for a test to request longer timeout.
With parallel test execution, the entire xpcshell test suite can execute in under 3 minutes on a fast machine (it's actually ~2 minutes when you throw out tests that only run sequentially). Having very long tests in the xpcshell test suite thus will become long poles during execution and decrease the time required to run the test suite. This in turn decreases automation efficiency. That's what you need to keep in mind. To mitigate the impact of long tests in our current automation world, I propose we annotate test manifest files (xpcshell.ini) with something saying a test is a "long" test. Long tests can be scheduled early during concurrent execution to mitigate the risk of them being a long pole. This annotation can also be used to determine the test timeouts. Despite the fact that 95% of xpcshell tests execute in under 10s (even during highly concurrent execution), we have an absurdly long default timeout that is universally applied. We should be able to drastically reduce the default timeout to minimize hang detection times in automation while still supporting long tests.
I do not think we have parallel execution. Anyway, this does not affect tests that do not opt-in into the longer timeout. The test in the linked bug takes 160seconds to run on a 3.5Ghz Phenom II CPU, but it is I/O bottlenecked. That is why it may take longer than 5 minutes on the try-servers. gps, you can still develop your solution (I can't) later in a new bug. But it will not help me right now with the mentioned test for Thunderbird. But I have no problem if you later rename the option for opting in to the "long test" behaviour.
Attachment #818027 - Flags: review?(ted)
Comment on attachment 818027 [details] [diff] [review] patch Review of attachment 818027 [details] [diff] [review]: ----------------------------------------------------------------- I could bikeshed over the key name, but I don't care that much.
Attachment #818027 - Flags: review?(ted) → review+
(In reply to :aceman from comment #2) > I do not think we have parallel execution. Sorry, this wanted to be "...parallel execution in comm-central xpcshell tests" . Thanks for accepting it. You can change the key name when gps continues with his plan. I also do not care about the name, as long as the functionality is there.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
This isn't documented anywhere, and it should be.
You need to log in before you can comment on or make changes to this bug.