Closed
Bug 826099
Opened 12 years ago
Closed 12 years ago
pushlog links for old m-c csets are timing out (triggering firefox error page) instead of loading
Categories
(Developer Services :: General, task)
Developer Services
General
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: dholbert, Assigned: fox2mike)
References
()
Details
STR: Try to load this URL:
https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=213ed838e5b7
(the "pushlog" link, from https://hg.mozilla.org/mozilla-central/rev/213ed838e5b7 )
ACTUAL RESULTS:
Firefox error page, saying
> The connection was reset
> The connection to the server was reset while the page was loading.
If I use 'curl' to download that URL, it times out with:
> curl: (18) transfer closed with outstanding read data remaining
Reporter | ||
Updated•12 years ago
|
Summary: Pushlog links for old csets aren't loading → pushlog links for old m-c csets are timing out (triggering firefox error page) instead of loading
Updated•12 years ago
|
Assignee: nobody → server-ops-devservices
Component: Hg: Customizations → Server Operations: Developer Services
QA Contact: shyam
Assignee | ||
Comment 1•12 years ago
|
||
How big is this pushlog? Also, can you try other formats, like json?
Assignee | ||
Comment 2•12 years ago
|
||
Weird.
fox2mike@woodpecker ~ $ time curl https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=213ed838e5b7
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
<head>
<link rel="icon" href="/mozilla-central/static/hgicon.png" type="image/png" />
<meta name="robots" content="index, nofollow"/>
<link rel="stylesheet" href="/mozilla-central/static/style-gitweb.css" type="text/css" />
<style type="text/css">
div.feed {
float: right;
}
a img {
border-width: 0px;
}
div.log_link {
width: 80px;
background-color: white;
}
div.log_body {
padding-left: 96px;
}
</style>
<title>mozilla-central: pushlog</title>
<link rel="alternate" type="application/atom+xml"
href="/mozilla-central/pushlog" title="Atom feed for mozilla-central pushlog"/>
<style type="text/css">
#localize, .expand {
font-size: x-small;
}
</style>
<script type="text/javascript" src="/mozilla-central/static/jquery-1.2.6.min.js"></script>
<script type="text/javascript">// <![CDATA
curl: (18) transfer closed with outstanding read data remaining
$(document).ready(function () {
real 0m41.289s
user 0m0.016s
sys 0m0.000s
Shouldn't die in 40 seconds, I'll poke a bit more.
Assignee | ||
Comment 3•12 years ago
|
||
As always, Daniel finds the weirdest stuff lol.
Trying with http gets me :
real 3m8.349s
user 0m0.012s
sys 0m0.132s
SOOOOO I know where the issue lies. Looking to fix.
Reporter | ||
Comment 4•12 years ago
|
||
(In reply to Shyam Mani [:fox2mike] from comment #3)
> As always, Daniel finds the weirdest stuff lol.
\o/
(I'll disregard comment 1, since I don't know the answer to either of the questions in it, and per comment 3, it sounds like they're not relevant anymore anyway.)
Assignee | ||
Comment 5•12 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #4)
> (In reply to Shyam Mani [:fox2mike] from comment #3)
> > As always, Daniel finds the weirdest stuff lol.
>
> \o/
>
> (I'll disregard comment 1, since I don't know the answer to either of the
> questions in it, and per comment 3, it sounds like they're not relevant
> anymore anyway.)
Correct and correct again!
Now I get :
fox2mike@woodpecker ~ $ time curl -I -L https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=213ed838e5b7
HTTP/1.1 200 Script output follows
Server: Apache/2.2.15 (Red Hat)
Vary: Accept-Encoding
Content-Type: text/html; charset=UTF-8
Date: Thu, 03 Jan 2013 04:22:45 GMT
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
ETag: 1357184346.3
Connection: Keep-Alive
real 2m58.257s
user 0m0.008s
sys 0m0.012s
So your earlier URL should load fine, after a few millenia ;)
There was a timeout set in the load balancer for https, which wasn't present on http. 3-4 mins is a bloody insane amount of time, but I'll let that slide for now. If we see issues with this, I'll reopen and revert.
Ted, is there any way we can cache pushlog requests like these? If the data is the same, this should be pretty simple to do? Thoughts?
Assignee: server-ops-devservices → shyam
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 6•12 years ago
|
||
Thanks! WFM too, now. (curl takes 2m58.747s)
Status: RESOLVED → VERIFIED
Comment 7•12 years ago
|
||
The pushlog data should be very cacheable. I'm not sure what sort of caching headers we send. The only tricky bit would be if someone requested a URL for a changeset that wasn't present, and then later that data became available, we wouldn't want to cache the mostly-empty response. I can't imagine that actually happens in practice, though, since nobody queries for changesets until they've been pushed.
Assignee | ||
Comment 8•12 years ago
|
||
I was thinking about something like memcached, but not sure how easy that would be. I can also look at Zeus for caching. Wondering if I should open a new bug to discuss this.
Comment 9•12 years ago
|
||
Yeah, let's do that. (I thought this was all behind Zeus at one point.)
Updated•10 years ago
|
Component: Server Operations: Developer Services → General
Product: mozilla.org → Developer Services
You need to log in
before you can comment on or make changes to this bug.
Description
•