Red Hat Bugzilla – Bug 457843
Last modified: 2013-06-23 22:17:00 EDT
This is with firefox-3.0.1-1.fc9.i386.
Watching a 2.6Ghz 8C Xeon workstation timeout on a single web-form after ~60 seconds at 100% is very amusing.
Far less amusing is the fact that firefox MT model is somewhat lacking - once a tab hangs @100%, the rest of the browser hangs with it...
*** Bug 458850 has been marked as a duplicate of this bug. ***
This problem got somehow critical with new bugzilla.. the search is almost impossible. How about to split the search form to more page?
Just for the reference:
The reason for this is that the new Bugzilla is now using classifications where we not before. The classifications drop down when selected will update the products in the product drop down depending on which ones are in the classification. Currently when the product list is updated due to a selected classification, it will try to update the components, version, and milestones as well which is why it will bog down the browser. I have made a modification in our code that will not automatically update the components, versions, and milestones list when selecting a classification. Only the products list will change. Then the user will need to select a product from the new list to have the others updated. I have added a mouseover for the word "Product" that will explain what will happen when a product is selected.
I feel this is a suitable fix for this until a better solution is found that handles large amounts of components in a more efficient way.
NEXTRELEASE means that this is not applied yet? I'm still experiencing timeouts with search page...
NEXTRELEASE in current Bugzilla context means next update which we try to roll out on Thursdays for non-critical fixes.
I did a shift-reload, and I see the popup for "Product". I'm no longer getting the timeout when I select a "Classification", but I am still getting it when I select a "Product".
I am still experiencing this problem when I select a Product, badly enough that I have to click "Continue" twice in dialog boxes which complain that "https://bugzilla.redhat.com/js/productform.js:290" is being unresponsive.
*** Bug 424691 has been marked as a duplicate of this bug. ***
We are pushing out an update to query.cgi that takes a more cgi approach to this issue and no longer relies on ajax to update the components/versions/milestones fields. Please open a new report after the update if the issue has not been resolved for you.
Well, I no longer get the popup messages and CPU hosage, so it looks like the burden has been shifted from the browser to the server. The page is still taking an annoyingly long time to load, though. Obviously I have no idea what the bottleneck is on the backend, but it would be more pleasant to file bugs if there could be caching or some other kind of workaround. Thanks for your efforts thus far!
Sorry, the slow loading is for filing new bugs, waiting for https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora
Here we're talking about query.cgi, where I'm actually seeing very quick performance, but I think the Component and Version lists are now malfunctioning. For example, if I choose "Fedora" and "Fedora" as Classification and Product, I can't find "smolt" on the Component list, and the Version field has 5.1, 5.1z, 5.2, 5.2z, 5.3, and 5.4. (It should have some integers running up through 10, plus "rawhide".)
(In reply to comment #12)
> Sorry, the slow loading is for filing new bugs, waiting for
Yes we are still working on a solution for enter_bug.cgi and is different than the query.cgi prodblem.
> Here we're talking about query.cgi, where I'm actually seeing very quick
> performance, but I think the Component and Version lists are now
> malfunctioning. For example, if I choose "Fedora" and "Fedora" as
> Classification and Product, I can't find "smolt" on the Component list, and the
> Version field has 5.1, 5.1z, 5.2, 5.2z, 5.3, and 5.4. (It should have some
> integers running up through 10, plus "rawhide".)
Did you click the "Refresh Components/Versions/Milestones" button below the product multi select field? You need to click that each time you change your product selections (not classifications). Maybe it needs to be more descriptive on what needs to be done?
Let me know if that works better.
Aha! I did not notice there was a new button. That's what I get for testing while sleepy. Thanks!
Oh yes, pressing this button is necessary, this should be more obvious. How about to move the Components, Version and Target below this button?
(In reply to comment #15)
> Oh yes, pressing this button is necessary, this should be more obvious. How
> about to move the Components, Version and Target below this button?
I will create a new bug for this and see if we can make this more intuitive. My first goal was to get the query.cgi to at least be usable to most people. The ajaxification of the products/components/versions/milestones made the page hang for long periods since the component lists for Fedora for example is over 7000 long now. The query.cgi page was never originally coded to handle that many components in a single product.
*** Bug 478313 has been marked as a duplicate of this bug. ***
*** Bug 489132 has been marked as a duplicate of this bug. ***