-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Content.py #107
Comments
Hi Mark, When you feel more comfortable/have the time to submit a pull request, I will gladly review it for you. I'll leave this ticket open for now. Thanks once again! |
Mark, It looks like you misunderstood job_pool.join(). If you look at the implementation, you will find it's waiting for all jobs in the queue to finish, instead of joining current job into the pool (which has been done by job_pool.push(job). Calling job_pool.join() too often will slow down the program, so I tried to avoid calling it unless there is an heuristic evidence that the consumer of the job queue is slower than the producer, indicated by "if processed_jobs < (queuesize / 5)" However, thanks for adding more comments and making variables more readable. |
Definitely, I didn't even look at the implementation. I was just guessing from how I saw it being used. Thank you for giving me the quick summary. So, my question is: do you see anything in the __process_finished_jobs (the old version) that might have been responsible for missed DB commit behavior I was seeing. Here's a more complete description of the problem I saw: If there were 11 total content jobs, the first 10 got inserted. When I added another content job -- by adding another commit to the underlying repository -- 11 of 12 content jobs got inserted. The 12th was processed and generated a DB insertion query, but it did not show up in the final DB -- almost as if there was no final connection.commit(). Of course, there was a final connection.commit() [at the end of .run()] both in the old code and the new code so that sort of rules it out as the source of the problem (unless a hidden exception was doing something funky). Thanks guys and have a good weekend. |
I reviewed the old code, and couldn't find anything responsible for the bug. The only change in your code that could change the behavior of the program is the removal of "if processed_jobs < (queuesize / 5)". If that fixed the bug, I would be surprised. |
Hi folks,
I know I should "git with it" and fork, mod, and make pull requests. I haven't done that and I'm SWAMPED with work. But, I'm trying to get my fixes (or at least, fixes for my needs) back to you. I hit a corner case in Content.py where the last ContentJob wasn't being flushed out to the database. Running cvsanaly2 with -g (debug) showed the query being made, but nothing was showing up in the DB. So, I did some mucking around and (1) rewrote Content.__process_finished_jobs() (based off of Blame.process_finished_jobs()) and (2) tweaked and cleaned up Content.run(). I don't know if I added some other regressions in the process.
Best,
Mark
The text was updated successfully, but these errors were encountered: