Studying the fix of JENKINS-47201 by Devin Nusbaum I suspect it was incomplete, as this block is not synchronized as a whole, and so two concurrent branches could both pick the same changelog file.
Looks like it, I think we could reorder some statements in the method so that we could lock Run when looking for the file without needing to lock prev as well, although maybe that code could be refactored to use the temp file APIs or something to be more robust.
Studying the fix of JENKINS-47201 by Devin Nusbaum I suspect it was incomplete, as this block is not synchronized as a whole, and so two concurrent branches could both pick the same changelog file.
{quote}
Looks like it, I think we could reorder some statements in the method so that we could lock {{Run}} when looking for the file without needing to lock {{prev}} as well, although maybe that code could be refactored to use the temp file APIs or something to be more robust.
David Aldrich I've attached an incremental build of the Pipeline SCM Step Plugin that contains PR #32. Feel free to try it out (preferably in a test environment first) to let us know if it addresses the problem. I am not sure when I will have time to test the code further myself and merge/release that change, so if you are blocked I would recommend testing that build.
Devin Nusbaum I have been running workflow-scm-step-2.8-rc326.7286a182d923.hpi for 3 weeks and have not seen a single instance of the SAXParseException. So it looks as though PR #32 fixes the problem.
Please will you consider releasing a formal update of the plugin?
[~dnusbaum] I have been running workflow-scm-step-2.8-rc326.7286a182d923.hpi for 3 weeks and have not seen a single instance of the SAXParseException. It has also been running fine with no resource locks for 3 days. So it looks as though PR #32 fixes the problem.
Please will you consider releasing a formal update of the plugin?
I'm having the same issue for. I'll use workflow-scm-step-2.8-rc326.7286a182d923.hpi to confirm if it's fixing the "ConcurrentModificationException". I'll test it against 100+ parallelized repositories (in groups fo 12 concurrent extractions)
I'm having the same issue for. I'll use workflow-scm-step-2.8-rc326.7286a182d923.hpi to confirm if it's fixing the "ConcurrentModificationException". I'll test it against 100+ parallelized repositories (in groups fo of 12 concurrent extractions)
I was having the same issue with a pipeline of 23 parallel checkouts. It was failing randomly.
I have installed plugin workflow-scm-step-2.8-rc326.7286a182d923.hpi and everything goes well now. Since installation, all 23 agents running in parallel are checking out correctly.
Is there a chance to get a new release of the plugin with this fix included? That would be great as this issue is really problematic for larger parallel pipelines.