Closed Bug 688256 Opened 13 years ago Closed 11 years ago

crash-stats doesn't display advanced search results

Categories

(Socorro :: General, task)

task
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: marcin.wasowski, Unassigned)

References

Details

(Whiteboard: [search])

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a2) Gecko/20110830 Firefox/8.0a2
Build ID: 20110830042010

Steps to reproduce:

Tried to display comparison chart for Fx ,6,7,8,9 and Fx3.x:
https://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A9.0a1&version=Firefox%3A8.0a2&version=Firefox%3A7.0b6&version=Firefox%3A6.0.2&version=Firefox%3A3.6.4pre&version=Firefox%3A3.6.3&range_value=1&range_unit=weeks&date=09%2F21%2F2011+12%3A53%3A24&query_search=signature&query_type=contains&query=&reason=&build_id=&process_type=any&hang_type=any&do_query=1


Actual results:

Service reported error:
Something bad happened. It's not you, it's me.
Please submit a Bugzilla ticket describing what happened, and please include the URL for this page.



Expected results:

self-explanatory
Status: UNCONFIRMED → NEW
Ever confirmed: true
Here's the error from the PHP side:

2011-09-21 13:56:01 -07:00 --- error: Web_Service 52 Empty reply from server while retrieving http://socorro-mware-zlb.webapp.phx1.mozilla.com/bpapi/201105/search/signatures/product/Firefox/version/Firefox%3A9.0a1%2BFirefox%3A8.0a2%2BFirefox%3A7.0b6%2BFirefox%3A6.0.2%2BFirefox%3A3.6.4pre%2BFirefox%3A3.6.3/in/signature/search_mode/contains/to/2011-09-21+12%3A53%3A24/from/2011-09-14+12%3A53%3A24/report_type/any/report_process/any/result_number/100/ which was HTTP status 0
2011-09-21 13:56:01 -07:00 --- error: Uncaught PHP Error: Trying to get property of non-object in file application/views/moz_pagination/nav.php on line 10
2011-09-21 13:56:01 -07:00 --- error: [5xx Error] File: application/views/moz_pagination/nav.php; Line: 10; Message: Trying to get property of non-object

Will track down that mware query next.
OK looks like the middleware search query is returning fine but since the webapp->mware request goes through the zeus loadbalancer, it times out after 30s.

Doing this request directly on the server I see it takes 39s :P

Perhaps we should just bump the timeout up here? We are planning on making this more efficient (with database work, ES will probably help too) but I don't think it'd hurt to make the timeout 60s or 120s, since it's possible to ask for a *very* large dataset with this UI.
Is this something we can slip into this Friday's release?
(In reply to Matt Brandt [:mbrandt] from comment #3)
> Is this something we can slip into this Friday's release?

This would be a setting on the Zeus load balancer that IT would have to change, so we'll need to get it on their radar by filing a new bug or moving this one to serverops (I'd say file a new one and make it dependent).

I can do that right now...
It also would be helpful if the feedback to the user could be better, i.e. if we could tell him that the query times out, probably because his dataset is too large.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #5)
> It also would be helpful if the feedback to the user could be better, i.e.
> if we could tell him that the query times out, probably because his dataset
> is too large.

We can't know this for sure until the query returns, but we could perhaps make an educated guess based on the aggregate data we have available (it will be stale obviously).

I am confident that we can make this much more responsive for all but the most pathological queries, though (both through PostgreSQL work and from providing ES as a search option).
Depends on: 688361
Component: Socorro → General
Product: Webtools → Socorro
Whiteboard: [search]
Depends on: 656297
Timeouts should have disappeared on search now that we use elasticsearch as a back-end.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.