modern.py was made from classic.py. It doesn't really need 'fetchTotalsForRange' internally anymore but it's still referenced.
Created attachment 552280 [details] [diff] [review] Fix the sql This patch removes the need for the function by rolling things up into one query.
Attachment #552280 - Flags: review?(peterbe)
Attachment #552280 - Flags: review?(peterbe) → review-
Created attachment 552948 [details] [diff] [review] better This is a technically superior patch. I rewrote it independently of the first, thinking I had already done this, only to find the original bug as I neared completion. Dates are converted using the isoformat method instead of str() as per Peter's original review. If this is r+ and I'm not around, feel free to land it for me.
Status: NEW → ASSIGNED
Target Milestone: --- → 2.2
Version: 1.0 → 2.2
Hmm I have been testing this on dev, but I notice after I click on 1-2 graphs on the topcrashers report, it stops working (just spins) and I start seeing requests like this in the middleware: /200911/topcrash/sig/trend/history/p/Firefox/v/6.0(beta)/sig/##empty##/end/2011-08-13+0000/duration/168/steps/60 (Note the "##empty##" sig) Is this a bug on the frontend? I don't see this problem in prod, just as a data point.
I tried 30 graphs in a beta build, including the empty sig, and I 2 of them take much longer than the others to finish but do eventually finish instead of timing out.
Comment on attachment 552948 [details] [diff] [review] better This code looks fine to me. I have been letting graphs spin for ~10 minutes which still haven't completed. If I try the URL logged by mware I get an error: [rhelmer@khan socorro-trunk]$ curl 'http://localhost:8080/200911/topcrash/sig/trend/history/p/Firefox/v/6.0b4/sig/hang | mozilla::plugins::PPluginInstanceParent::CallNPP_HandleEvent(mozilla::plugins::NPRemoteEvent const&, short*)/end/2011-08-13+0000/duration/168/steps/60' Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/web.py-0.33-py2.6.egg/web/wsgiserver/__init__.py", line 1170, in communicate req.parse_request() File "/usr/lib/python2.6/site-packages/web.py-0.33-py2.6.egg/web/wsgiserver/__init__.py", line 307, in parse_request self._parse_request() File "/usr/lib/python2.6/site-packages/web.py-0.33-py2.6.egg/web/wsgiserver/__init__.py", line 387, in _parse_request rp = int(req_protocol), int(req_protocol) ValueError: invalid literal for int() with base 10: 'i' This is because the URL isn't encoded, if I encode it everything is fine. I'll take a quick look at the frontend code.
Attachment #552948 - Flags: review?(rhelmer) → review+
(In reply to Robert Helmer [:rhelmer] from comment #5) > This is because the URL isn't encoded, if I encode it everything is fine. > I'll take a quick look at the frontend code. Nevermind, I withdraw my concern - I checked and the frontend is urlencoding (using PHP rawurlencode) and it's all fine. If you can't repro what I am seeing on dev, I am find going ahead with this and testing on stage - it definitely fixes a known issue, if there are further issues we can reopen or open a new bug.
(In reply to Robert Helmer [:rhelmer] from comment #6) > seeing on dev, I am find going ahead with this and testing on stage - it "... fine going ahead with this and testing on stage"
Yep. I cannot repro. We can deal with the intermittent failures if they arise as a separate issue. Landed: trunk: r3438 http://code.google.com/p/socorro/source/detail?r=3438 branch: r3437 http://code.google.com/p/socorro/source/detail?r=3437
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.