Wayne Mery (:wsmwk) Reporter
	Description • 16 years ago

consistent "The connection to the server was reset while the page was loading." on crash-stats search with "top 10 stack frames contains trash" 

http://crash-stats.mozilla.com/?do_query=1&product=Thunderbird&query_search=stack&query_type=contains&query=trash&date=&range_value=3&range_unit=months

	Michael Morgan [:morgamic] Assignee
	Comment 1 • 16 years ago

I would recommend shortening the date range, but we should probably have a fulltext index on signature and top 10 frames if we are going to need this to be feasible.  ->0.6

	Marcia Knous [:marcia]
	Comment 2 • 16 years ago

I hit this same bug periodically, but it is not in the case of a crash stats search. I hit it in the office and at wifi access points.

	Wayne Mery (:wsmwk) Reporter
	Comment 3 • 16 years ago

related to bug 423009?

	Mark Smith [:xb95]
	Comment 4 • 16 years ago

That page doesn't seem to load for me.  Just spins.  Does it normally take a long time for it to load?

I don't know if it's specifically related to the BMO bug or not.  I've not investigated the non-BMO cluster to see if it's exhibiting the same symptoms of Apache rolling over after every request.

	Wayne Mery (:wsmwk) Reporter
	Comment 5 • 16 years ago

Mark, It can take several seconds to a minute or two ..., depending on the query.  However, the issue reported by this bug started same time as bug 423009.

The url in comment 0 still fails with "reset while page was loading"

	Wayne Mery (:wsmwk) Reporter
	Comment 6 • 16 years ago

Morgamic in comment 1 is on to it.  Mossop reports similar (maybe same) issue in Bug 424952 – Queries can be too slow. 

I played this morning with Product=Thunderbird, starts with "JS_strtod". It should return results page in less than a minute or two even for time period of a couple months.  It often fails to return results for 2-3 weeks.

Once you get results page for a time period, if you do another query within a minute or two using the same length time period but with different signature the results come back within a few seconds.  Example:
- get reults of JS_strtod, time period of 4 weeks and thereafter it returns results in 3 seconds.
- change query to zzz, use same 4 weeks, results return in a few sec.
- change query to 5 weeks (with "zzz"), blammo - good luck getting results page

I'm marking regression because I didn't see this problem before a few weeks ago (mid-march maybe?). 

=> Query is not scaling and is pretty much unusable, so maybe it should be sev=critical. Even period=2 weeks can take 3-5 minutes to get results, IF you get results.  what's the next milestone to be pushed out that might fix this?

	Wayne Mery (:wsmwk) Reporter
	Comment 8 • 16 years ago

unusable (no results) this morning searching 1 week period for 
  firefox + branch=1.9 + nsDocLoader::QueryInterface + 1 week
adding version to the selection criteria helps get a response

ditto http://crash-stats.mozilla.com/topcrasher/byversion/Thunderbird/3.0a1pre - no response for first couple attempts.

this thing needs a *serious* performance bump.

	chris hofmann
	Comment 9 • 16 years ago

yeah, it seems to be getting worse.  standard queries that were working fine a few days and weeks ago now are unable to run.

I know ted is back from vacation and morgammic and others have this pretty high on the list to get improved.

we really need it fixed by next week with firefox 3 RC1 gets released so we can stay on top of what happening with incoming crash reports.

	(not currently active) Ted Mielczarek
	Comment 10 • 16 years ago

I believe this is primarily due to the database partition getting too large. See bug 432448, bug 432449, bug 432450.

	Mats Palmgren (inactive)
	Comment 12 • 16 years ago

It would be good if someone could take a look at this bug so we can use
this server to get a picture of the crash bugs we still have in RC1.

	chris hofmann
	Comment 13 • 16 years ago

aravind,  do you have cycles to help on this?

these bugs are pretty much blocking analysis on firefox 3 rc1 that is going out in the next day or so.

  [See dependency tree for bug 422908]
bug 432448: Add new partition [NEW ; assigned to nobody@mozilla.org; Target: 0.5] 

bug 432449: Add date constraints to older partitions [NEW ; assigned to nobody@mozilla.org; Target: 0.5]

bug 432450: Create script to auto-archive old records and create new partitions when needed [NEW ; assigned to nobody@mozilla.org; Target: 0.5] 

	Steven Michaud [:smichaud] (Retired)
	Comment 14 • 16 years ago

Here's a trick that (at least sometimes) gives me better results:

Say I want to do a search over two weeks of crash records, but that
always times out.

Instead I try the same search over 1 day's worth of records -- which
works.  Then I try it over (say) 3 days, then 7 days, then two weeks
-- all in quick succession, each time waiting for the previous one to
succeed.

	Steven Michaud [:smichaud] (Retired)
	Comment 15 • 16 years ago

(Following up comment #14)

This trick appears to have stopped working :-(

	Tony Chung [:tchung]
	Comment 16 • 16 years ago

Hi there, can we get some extra traction on this bug?  Its getting worse now and more common to reproduce now.   And this data is important to analyze for qa.  Thanks.

	Wayne Mery (:wsmwk) Reporter
	Comment 17 • 16 years ago

I now can't even get a 1 day span. It's unusable

	Felipe Contreras
	Comment 18 • 16 years ago

I can't even get one crash report:
http://crash-stats.mozilla.com/report/list?range_unit=weeks&version=Firefox%3A3.0.1&range_value=2&signature=nsFrame%3A%3ABoxReflow%28nsBoxLayoutState%26%2C+nsPresContext%2A%2C+nsHTMLReflowMetrics%26%2C+nsIRenderingContext%2A%2C+int%2C+int%2C+int%2C+int%2C+int%29

	Tony Mechelynck [:tonymec]
	Comment 19 • 16 years ago

IIUC, ATM only individual crash reports (such as linked from about:crashes) can be had from the Socorro servers. Everything else fails, and in particular complex queries like the one in comment #18.

See also bug 444749.

	Dave Townsend [:mossop]
	Comment 20 • 16 years ago

(In reply to comment #19)
> IIUC, ATM only individual crash reports (such as linked from about:crashes) can
> be had from the Socorro servers. Everything else fails, and in particular
> complex queries like the one in comment #18.
> 
> See also bug 444749.

The individual crash reports are taking minutes to load for me, raising severity and requesting blocking.