Closed (fixed)
Project:
Drupal.org infrastructure
Component:
Git
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
13 Jun 2014 at 22:01 UTC
Updated:
19 Apr 2019 at 00:19 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
drummDuring DrupalCon, the cron-versioncontrol_repository_event_processor-drupal.org job did get stuck for ~4 days. Certain commits cause it to OOM and currently have to be killed manually. I've added my log of killed queue items to the issue summary.
Comment #2
drummI was able to re-run the queue worker on util for the three commits with code like:
The comments now show up normally, although late. The code completed normally and quickly, so they were indeed not the cause of any problem, but collateral damage from last week's trouble.
Doing the same type of debugging on git7site with the killed queue items should run into the memory leak and let us get to the root cause.
Comment #3
jhodgdonThanks! Good luck with the debugging... I wasn't so concerned about having those particular commit messages added, as making sure someone was aware that it had happened. Looks like you already were.
Comment #4
marvil07 commentedI have not yet tried to replicated this, but I took a look at the related event data for killed items and I found a pattern(update: see file in next comment, it just looks bad inline here).
All of those events are adding a new branch to a drupal core repository clone in a sandbox.
So by best guess is that it is trying to parse the full history of the branch, which start at drupal core repository first commit, which takes time and probably can cause a OOM.
Comment #5
marvil07 commentedComment #6
drummAdding
a:2:{s:7:"repo_id";s:5:"18942";s:4:"elid";s:6:"968389";}to the killed list.Comment #7
drummAdding
Comment #8
drummAdding
Comment #9
drumma:2:{s:7:"repo_id";s:5:"42576";s:4:"elid";s:6:"978983";}Comment #10
drumma:2:{s:7:"repo_id";s:5:"68201";s:4:"elid";s:6:"981221";}Comment #11
danchadwick commentedA couple of days ago, commit messages for the webfor 7.x-4.x branch stopped being automatically posted. I generally push to both the 7.x-4.x branch and 8.x-4.x branch at the same time. I am getting commit messages for the 8.x-4.x branch.
List of recent commit messages:
https://www.drupal.org/node/7404/commits
Here's an example issue:
https://www.drupal.org/node/2467877
Here the 7.x-4.x branch commit that doesn't have a comment in the issue:
http://cgit.drupalcode.org/webform/commit/?id=755af13a6964bc621ad8795f0e...
Comment #12
drummThat looks like a separate issue, maybe related to #2329677: Branch missing in commit comment or another issue in https://www.drupal.org/project/issues/versioncontrol_project?text=commen.... Likely something in the logic in, or called by, http://cgit.drupalcode.org/versioncontrol_project/tree/versioncontrol_pr...
Comment #13
jhodgdonI'm having this problem the past several days with my Sandbox module:
https://www.drupal.org/sandbox/jhodgdon/2369943
This module used to get commit messages. For example, here is a closed issue from April with one:
#2873475: WSOD in the help-topic Page.
But there have been numerous commits in the past few days and none of them has shown up. Here's one example:
#2920479: Get rid of rendering in hook_help
http://cgit.drupalcode.org/sandbox-jhodgdon-2369943/commit/?id=ee7dd80
Should I make a new issue?
Comment #14
jhodgdonAbout 22 hours ago, all the commit messages for the past week suddenly showed up in the module mentioned in #13. So, whatever was broken suddenly got fixed... thanks whoever took care of that!
Comment #15
drummThat was me. The versioncontrol event processor queue which posts these comments, among other things, was jammed up for quite awhile until I tracked down the root cause.
Comment #16
markhalliwellThis seems to be happening again :-/ Last 6 commits haven't posted to the related issue: https://www.drupal.org/node/259843/commits
Comment #17
drummThis is catching up now. A job needed to be deleted to unblock the queue.
Comment #18
drummWe’ve caught up reposync for all Drupal.org repositories, including core sandboxes, and a few with things like thousands of files added or removed in a single commit. This is working well with the GitLab integration code we’ve built.
Comment #19
marvil07 commented@drumm that is great to hear!