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[0] == > 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. --nate > > Thanks, > > -Amir > > > ___________________________________________________________ > 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: > > http://lists.bx.psu.edu/ ___________________________________________________________ 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: http://lists.bx.psu.edu/
