On Aug 17, 2012, at 10:54 AM, Karger, Amir wrote:
> 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 ==
> self.server_name ) and ( self.job_manager == self.server_name ):
> self.track_jobs_in_database = False
Yeah, this logic doesn't correctly handle the situation (below) where you have
a single manager/handler but separate web processes.
> 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.
I've made it possible to manually set track_jobs_in_database in
universe_wsgi.ini in 244b4cb100d1.
> 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:
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: