| Anonymous | Login | Signup for a new account | 2010-07-29 10:22 EDT |  |
| Main | My View | View Issues | Change Log | Roadmap | Wiki | ManTweet | Repositories |
| View Issue Details [ Jump to Notes ] [ Wiki ] | [ Issue History ] [ Print ] | |||||
| ID | Project | Category | View Status | Date Submitted | Last Update | |
| 0003798 | mantisbt | bugtracker | public | 2004-04-30 13:42 | 2008-08-12 09:36 | |
| Reporter | dfaught | |||||
| Assigned To | grangeway | |||||
| Priority | normal | Severity | major | Reproducibility | sometimes | |
| Status | closed | Resolution | unable to reproduce | |||
| Platform | OS | Debian Linux | OS Version | 3.0 | ||
| Product Version | 0.18.2 | |||||
| Target Version | Fixed in Version | |||||
| Summary | 0003798: Locked out of View Bugs page after large query | |||||
| Description | I ran a stress test script to create a project with a large quantity of bugs (16257 bugs at the moment). I tried to generate a report of all bugs in the project - I went to the View Bugs screen and entered "20000" in the "Show" field and clicked "Apply Filter". The result was a blank page. The html sent back was: <html><body></body></html> After this happens, every time I try to go to the View Bugs page from the same account I get this blank page. I have to delete the MANTIS_VIEW_ALL_COOKIE to be able to see this page again. I found that values in the Show field less than 475 worked fine and produced the report as requested. Values above 475 always produced the blank screen. 475 itself worked intermittently. I restarted Apache and found that reports with 500 records worked okay, but when I asked for 20,000 again, I again got the blank screen. This time the threshold was around 496. Doing reports on the bugs.mantisbt.org, it has no problem reporting the 1900 or so bugs there when I set the Show field to 20,000. Perhaps the difference in total bugs in the database is a key factor. I have not tried other platforms or tried to create another large project to see how easy it is to reproduce. For a user who doesn't know how to manage cookies, this could be a showstopper for them if they're using a large bug database. | |||||
| Additional Information | I'm using Apache 1.3.6, PHP 4.1.2, and mysql Ver 11.16 Distrib 3.23.49 on Debian 3.0, accessing the server using IE 6 and Netscape 7.1 on Windows XP. | |||||
| Tags | blank screen | |||||
| Attached Files | ||||||
 Relationships |
|
 Relationships |
|
Notes |
|
 (0005468)Apel (reporter) 2004-05-04 05:50 |
Although I don't know the real cause of the problem (memory?) I'd suggest to limit the maximum number of bugs a user can view per page via pref. It makes no sense (or does it?) to display thousands of bugs on one page and puts unneccessary load on the server. |
 (0005469)dfaught (reporter) 2004-05-04 09:04 |
Limiting the number of bugs that can be viewed means that's the maximum number of bugs that can be printed to a report. We'd need to document that Mantis is not designed to handle over X number of bugs for a project, unless a feature were added to report on more bugs than can be printed on a single web query (perhaps a good idea). Let's see if someone can find the cause of the problem. |
 (0005554)int2str (reporter) 2004-05-22 07:13 |
Sounds a little bit like the maximum script execution time may have been exceeded. Raise the script execution time in php.ini and try again. |
 (0006556)grangeway (developer) 2004-08-02 12:48 |
Are you able to test this against 0.19 on a test db and see if you can still reproduce this issue? |
 (0007264)Narcissus (developer) 2004-08-27 22:30 |
This has got to be related to the script max execution time. I know that IE, for example, will show <html><body></body></html> as the page source if there isn't actually any source to show (like when the script timeouts without ever sending any real information). I'm wondering: Maybe we should code up a 'timeout catch' function. This could operate by checking the current execution time against the max_execution_time (for example, while looping through the bugs, generating HTML). If we get to a point where we're still working and only have maybe 1 second before hitting the max time, we cancel what we're doing and instead create a new page that resets the filter values and prints an error message of some sort. That way, the user knows what happened (and why), plus they don't end up with unusable filter settings. Thoughts? |
|
(0018443) grangeway (developer) 2008-07-13 13:04 |
Hello, Marking this issue as resolved - no recent feedback and performance of some mantis bottlenecks has been improved in latest releases. Paul |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2004-04-30 13:42 | dfaught | New Issue | |
| 2004-04-30 16:03 | dfaught | Issue Monitored: dfaught | |
| 2004-05-04 05:50 | Apel | Note Added: 0005468 | |
| 2004-05-04 09:04 | dfaught | Note Added: 0005469 | |
| 2004-05-22 07:13 | int2str | Note Added: 0005554 | |
| 2004-08-02 12:48 | grangeway | Note Added: 0006556 | |
| 2004-08-27 19:48 | grangeway | Status | new => feedback |
| 2004-08-27 22:30 | Narcissus | Note Added: 0007264 | |
| 2004-08-27 22:30 | Narcissus | Issue Monitored: Narcissus | |
| 2007-11-28 14:21 | Martin Fuchs | Tag Attached: blank screen | |
| 2008-07-13 13:04 | grangeway | Note Added: 0018443 | |
| 2008-07-13 13:04 | grangeway | Status | @0@ => resolved |
| 2008-07-13 13:04 | grangeway | Resolution | @0@ => unable to reproduce |
| 2008-07-13 13:04 | grangeway | Assigned To | => grangeway |
| 2008-08-12 09:36 | grangeway | Status | resolved => closed |
|
Issue History |
| MantisBT 1.2.2 git master-1.2.x[^]
Copyright © 2000 - 2010 MantisBT Group
Time: 0.2400 seconds. memory usage: 1,967 KB |
 |