-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WSOD for large XML file #12
Comments
Would this result in a (HTTP error code) 500 error? EDIT (googles white screen of death.... yep, OK, thats our problem) The user im troubleshooting with will get an HTTP 500 error and not be able to display the job page if he sets the max hit limit to 250. (Setting it to 500 and your failsafe kicks in). Setting to 100, and the page loads. We can check the logs and see that the blast job ran successfully in all cases. So it sounds like for HWG implementing your module, 250 is somewhere between your fix and what our server can manage. I can change the code on our local branch to cut off at 101 instead of at 500. |
Possible solutions:
Reactions? Any other ideas? |
Hmmmmm.... my gut reaction is that #4 is the safest but I worry since BLAST is a heuristic we would end up with results shown on the page that are not in the downloadable files :-( |
I have an operational proof-of-concept for option 4, but the concern about getting different results from the second BLAST execution is very valid ... and quit likely to happen. Unfortunately, blast_formatter won't permit limiting hsps like the BLAST programs do. |
What about if we do a combination of #2 & #3? A takes care of the HSPs and B takes care of the hits keeping us in a safe zone and ensuring we have the same results on the page as in the files. There is still a little bit of rope for people to hang themselves but it is MUCH better then where we are currently at. Thoughts? |
Hmm. I'll play with this idea for a bit. |
Ok, thanks for taking this one on and Yay for coffee and a fresh morning ;-) |
Hello. I tried blast recently with a huge file and am getting the same problem. Sample given below
Target:
I am either getting a memory error such as
or a "gatekeeping timeout" error. But the files are getting generated and stored... Edit 1: I tried blast in blast website using the same files and got this error Edit 2: When I tried blasting in the web ui using a very small query size, I am getting some results but I am getting more errors (hundreds which are basically repetitions of the same few)
|
There is a known problem that if a user has a large blast result XML file (exact size depends on your web server) they might end with a memory exhausted WSOD. This is due to the XML reader we use reading the entire file into memory.
We have mostly mitigated this issue by checking the number of hits using grep and then only reading the XML if it is below a static threshold (currently 500). However, there appear to be some edge-cases that this still happens in and of course, if your particular server has issues with even 500 hits then this will still be a problem.
Furthermore, since we simply just don't read the XML we can't even show you a subset of hits or a summary which would be more useful in the case of large resultsets then simply forcing the user to download TSV and go from there.
In the future I would like to move to a stream-based XML reader (http://php.net/manual/en/class.xmlreader.php) to completely remove this issue.
The text was updated successfully, but these errors were encountered: