Skip to content
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

[JENKINS-53358] Remove bogus persistence calls due to notifyListeners #234

Draft
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

svanoort
Copy link
Member

@svanoort svanoort commented Jul 11, 2018

JENKINS-53358

These should not be invoked in performance-optimized durability mode -- if we're not trying to save with each step run, we shouldn't do it due to listeners firing. This was an issue that degraded the IO improvements for performance-optimized mode and greatly increased IO calls. The phrase "CD-660" may be meaningful to some here.

Also fixes a buglet noted with the persistedClean flag handling.

@svanoort svanoort requested a review from jglick August 30, 2018 21:54
@svanoort svanoort changed the title [WIP] Remove bogus persistence calls due to notifyListeners Remove bogus persistence calls due to notifyListeners Aug 30, 2018
@svanoort svanoort changed the title Remove bogus persistence calls due to notifyListeners [JENKINS-53358] Remove bogus persistence calls due to notifyListeners Aug 30, 2018
@@ -143,7 +143,8 @@
<dependency>
<groupId>org.jenkins-ci.plugins.workflow</groupId>
<artifactId>workflow-job</artifactId>
<version>2.21</version>
<!--<version>2.23</version> -->
<version>2.25-rc775.35b435d87ee7</version>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only until I cut the release, then it will be converted to the final release version and this will be cleaned up

Copy link
Member

@dwnusbaum dwnusbaum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

testNondurableResetsCleanlyPersistedFlag is failing in the CI build.

testPluginActive is also failing because the new workflow-job version requires Jenkins 2.73.3 but the baseline here is 2.60.2, so you either need to change the Jenkinsfile here so it doesn't build against 2.60.2, or to bump the baseline here to 2.73.3. I think the latter makes more sense, since otherwise we can't test against the actual baseline, and anyone running this update without the latest version of workflow-job may hit JENKINS-50199 more often so they should probably update both plugins at the same time anyway.

} else if (!(getDurabilityHint().isPersistWithEveryStep()) && !(nodes.stream().anyMatch(x->x instanceof FlowEndNode))) {
// We do not want to invoke gratuitous save calls if we aren't set to persist with every step
// Except that we MUST trigger a persistence call at the very end of the execution
bc.abort();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We aren't worried about whether this causes JENKINS-50199 to happen more often because even if it does, it should only matter when reloading configuration from disk, and that case is now handled by jenkinsci/workflow-job-plugin#104, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dwnusbaum Correct -- and if the cause of JENKINS-50199 is still triggered, then that's a bug somewhere else -- if we were relying on this to trigger persistence, that's a clear bug.

@svanoort
Copy link
Member Author

Sigh, looks like some more test flakiness to sort out (AFAICT the hangs are tied to copyLogs, so releasing and incorporating the log-handling rewrite may solve that).

@svanoort
Copy link
Member Author

@@ -1441,7 +1441,11 @@ void notifyListeners(List<FlowNode> nodes, boolean synchronous) {
}
} finally {
if (synchronous) {
bc.abort(); // hack to skip save—we are holding a lock
bc.abort(); //// hack to skip save—we are holding a lock
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the introduced //?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to see if people are paying attention

@jglick
Copy link
Member

jglick commented Oct 13, 2018

I guess this is on hold?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants