We had the same problem while we were running on Galaxy server then we moved to 
cluster it worked fine.
 
Vasu
--- On Thu, 1/13/11, Kelly Vincent <kpvinc...@bx.psu.edu> wrote:


From: Kelly Vincent <kpvinc...@bx.psu.edu>
Subject: Re: [galaxy-dev] bowtie hanging after execution
To: "Branden Timm" <bt...@wisc.edu>
Cc: galaxy-...@bx.psu.edu
Date: Thursday, January 13, 2011, 12:30 AM


Branden,

Which revision of Galaxy are you using? What this sounds like is that it is 
taking a long time to set the metadata on the resulting SAM file, i.e., after 
the Bowtie job has run. Prior to 4698:48a81f235356 (12/1/10), all the lines in 
a large SAM file would be read to determine how many lines there were--this 
could take a very long time. But that changeset made it so that it gave up if 
the file was too large and did not set the number of lines. However, in 
4842:7933d9312c38 (1/12/11), this was changed so that if the file is too large, 
it generates a rough estimate of the number of lines.

Regards,
Kelly


On Jan 12, 2011, at 5:32 PM, Branden Timm wrote:

> Hi All,
>  I am seeing a strange problem with Galaxy and bowtie.  Here is the scenario:
> 
> 1) I run bowtie for Illumina data (bowtie 0.12.5 Linux x86_64) on a 
> fastqsanger input generated by FASTQ-Groomer
> 2) On the system, I see the bowtie_wrapper and bowtie subprocesses start, 
> with bowtie distributing across the four cores in the system
> 3) The bowtie and bowtie_wrapper processes stop a few minutes later, but the 
> history item still shows that it is running.  This happens for about 20 
> minutes.  Paster.log show constant POST history_item_updates activities every 
> three seconds, and the Galaxy server process itself hogs 100% of one of the 
> system's cores.
> 
> I've tried this both on our production galaxy site (RHEL 5.5, Python 2.4.3) 
> and my local workstation (RHEL 6, Python 2.6.5).
> 
> As part of my troubleshooting, I've extracted the bowtie_wrapper command from 
> paster.log and run it on the command line.  The tool completes successfully 
> in a few minutes, which confirms that the Galaxy server process seems to be 
> the culprit in this situation, not bowtie_wrapper.
> 
> Any help would be greatly appreciated.  Cheers
> 
> --
> Branden Timm
> University of Wisconsin
> Great Lakes Bioenergy Research Center
> bt...@glbrc.wisc.edu
> 
> _______________________________________________
> galaxy-dev mailing list
> galaxy-dev@lists.bx.psu.edu
> http://lists.bx.psu.edu/listinfo/galaxy-dev

_______________________________________________
galaxy-dev mailing list
galaxy-dev@lists.bx.psu.edu
http://lists.bx.psu.edu/listinfo/galaxy-dev



      
_______________________________________________
galaxy-dev mailing list
galaxy-dev@lists.bx.psu.edu
http://lists.bx.psu.edu/listinfo/galaxy-dev

Reply via email to