Do you have 'debug = True' in universe_wsgi.ini on this server? This enables middleware that will attempt to load the entire response into memory. --nate Chris Cole wrote:
Hi Nate,
We tried a BWA run this morning and this time it gave an error rather than a crash. Below is just the python error output, I can give a sanitised full output if you prefer.
However, I can't do any more testing for the time being as the hardware on our development server has gone to the Great Cluster in the Sky RIP. We do have a replacement which will be in place soon. In the meantime, any help appreciated.
Chris
Server Error URL: http://wsdev.compbio.dundee.ac.uk:3216/datasets/ec351b7f7460a3bb/display?to_...
Module paste.exceptions.errormiddleware:143 in __call__ << try: __traceback_supplement__ = Supplement, self, environ app_iter = self.application(environ, start_response) return self.make_catching_iter(app_iter, environ) except:>> app_iter = self.application(environ, start_response) Module paste.debug.prints:97 in __call__ << threadedprint.register(replacement_stdout) try: status, headers, body = wsgilib.intercept_output( environ, self.app) if status is None:>> status, headers, body = wsgilib.intercept_output( Module paste.wsgilib:552 in intercept_output << if len(data) < 2: data.append(None) data.append(output.getvalue()) return data>> data.append(output.getvalue()) MemoryError: extra data
Hi Chris,
Are you using 'run.sh --daemon' or just 'run.sh' (and daemonizing/backgrounding through some other method, like 'screen')? I'm asking because it's odd that there's no traceback or even something like a segfault (which would only be seen if run in the foreground).
If you're starting with --daemon, could you start in the foreground, cause the crash, and see if anything is output when it happens?
Thanks, --nate
Thanks,
Chris
On 05/01/10 11:18, Chris Cole wrote:
Hi Kelly,
Just getting back to this following the holidays.
On 22/12/09 21:32, Kelly Vincent wrote:
Hi Chris,
Can you confirm that you have a recent changeset (today we're at 3192:828d9f9dcb29)?
'hg tip' returns 3137:ddd9d5ac0457
If you're using an earlier version, either update or check that <Galaxy root>/lib/galaxy/datatypes/registry.py contains the following line: 'sam' : 'text/plain', (it should be line 164, as part of the self.mimetypes_by_extension dictionary definition).
Yup, it's there
In either case, make sure the line: <datatype extension="sam" type="galaxy.datatypes.tabular:Sam" display_in_upload="true"/> appears in <Galaxy root>/datatypes_conf.xml. It should be around line 51, inside the tag: <registration converters_path="lib/galaxy/datatypes/converters">
Nope. Not in there.
I've added it and it works for small files, but not large ones. Small is 119 lines and large 20 million lines. There are no errors in paster.log, now. Galaxy simply falls over.
Would an update solve it? Thanks for your help,
Chris
Let us know what you find.
Regards, Kelly
On Dec 18, 2009, at 11:35 AM, Chris Cole wrote:
Hi,
On our local install, we've just enabled bowtie NGS mapping and although the search runs fine and the output is viewable in Galaxy, any attempt to save it brings down the server.
The only error in paster.log is: galaxy.datatypes.registry WARNING 2009-12-18 16:32:38,517 unknown mimetype in data factory sam
Tried it on large files and small files with the same effect.
Trying save as fails with an 'unable to read file error'. Anyone have any ideas? Cheers,
Chris