Persistent job queue prodcom #44
Conversation
…sing the job to get scheduled repeatedly. This needs to be fixed by loading the job object from redis to memory, changing what needs to changed (like appending trace), and then writing it eat back to redis. This commit is an early attempt at doing this.
|
I'm making this the master since it doesn't change anything with Redis off (tested, and deployed to greatwhite with proper nginx setup). We can continue other feature debates from new PRs to the master. |
|
Given the persistent job queue, it's very important that there be a way to It's also not clear to me what would (should) happen to running jobs in the -- David O'Hallaron On Wed, Mar 18, 2015 at 7:55 AM, Ilter notifications@github.com wrote:
|
|
We have a resetTango method (https://github.com/autolab/Tango/blob/master/tangod.py#L178) and it gets called whenever the app starts, but I don't think it actually resets the jobQueue. I will change it so that it clears the jobQueue on Redis as well. Also, on the prod-com model, I think having new producers should not reset Tango. There should only be one consumer, and tango should return to initial state when there is a new consumer. |
The main purpose of this merge is to organize the project:
After these changes, Tango can be daemonized with Supervisor and run though Nginx. So on surface, nothing has changed. With Redis off, it works the same way as the current Tango.
The merge also includes two other more substantial changes:
tangoReseton start twice (let's say if we started 2 tangos on the same machine)