On 8/16/12 4:18 PM, "Karger, Amir" <amir_kar...@hms.harvard.edu> wrote:

>On 8/8/12 4:06 PM, "Nate Coraor" <n...@bx.psu.edu> wrote:
>>If you aren't setting job_manager and job_handlers in your config, each
>>server will consider itself the manager and handler.  If not configured
>>to run jobs, this may result in jobs failing to run.  I'd suggest
>>explicitly defining a manager and handlers.
>Sigh. We have both job_manager and job_handlers set to the same server.
>It seems like our runner app may be getting into some kind of sleeping
>state. I was unable to upload a file, which had worked before. However,
>when I restarted the runner, it picked up the upload job and successfully
>uploaded it AND picked up the previously queued tab2fasta job, and I
>believe completed it successfully too.

Replying to myself.

The reason the runner was in a "sleep" state is the logic in
lib/galaxy/web/config.py says:

        if ( len( self.job_handlers ) == 1 ) and ( self.job_handlers[0] ==
self.server_name ) and ( self.job_manager == self.server_name ):
            self.track_jobs_in_database = False

For our dev instance, we have a single server acting as the job manager
and the job handler, and we have two web servers also running on the dev
box. So Galaxy apparently decides not to track the jobs in the database.
However, this means it never finds any jobs to run. When we explicitly set
self.track_jobs_in_database to be true in config.py, Galaxy correctly
finds and runs jobs.

I guess the webapps think that Galaxy *is* tracking jobs in the database,
so they put jobs in there that never get pulled out? Or should it actually
work when track_jobs_in_database is false, as long as the job manager and
job handler(and webapps?) are on the same server. In that case, do we know
why it didn't work? I'm happy to be running track_jobs_in_database=True,
because our prod server is going to have separate machines doing web vs.
job handling/managing.



Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:


Reply via email to