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-68417] Revert LogRecord tricks #6643

Merged
merged 8 commits into from
Jul 6, 2022

Conversation

jglick
Copy link
Member

@jglick jglick commented Jun 9, 2022

See JENKINS-68417.

Reverts #6018 and #6449; keeping synchronization simplifications from #6018, the correction to those in #6044, and (slightly amended) test coverage. All “published” log records (INFO and above, or finer if in a custom logger) are retained, but if there are parameters with a message format, that format is expanded at publishing time so that the parameters can be discarded, solving any memory leak issues at the cost of a bit of extra CPU work for custom loggers which the admin never actually looks at. jenkinsci/workflow-cps-plugin#557 seems to suffice.

Proposed changelog entries

  • Reverting prior attempts to make log records collectible.

Maintainer checklist

Before the changes are marked as ready-for-merge:

  • There are at least 2 approvals for the pull request and no outstanding requests for change
  • Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
  • Changelog entries in the PR title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood
  • Proper changelog labels are set so that the changelog can be generated automatically
  • If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
  • If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

core/src/main/java/hudson/util/RingBufferLogHandler.java Outdated Show resolved Hide resolved
core/src/main/java/hudson/util/RingBufferLogHandler.java Outdated Show resolved Hide resolved
}
}
synchronized (this) {
int len = records.length;
Copy link
Member Author

Choose a reason for hiding this comment

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

hide whitespace in diff

jglick added 3 commits June 10, 2022 13:29
…in CI, not locally, but anyway Javadoc says a `null` `LogRecord` is permitted, and test should not bypass the interesting logic
Copy link
Member

@basil basil left a comment

Choose a reason for hiding this comment

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

Very nice! The original motivation behind #6018 was BOM/PCT failures, so I think we should run BOM/PCT on this to ensure that the partial revert of #6018 does not expose any old BOM/PCT failures again.

Comment on lines +79 to +81
if (record == null) {
return;
}
Copy link
Member

Choose a reason for hiding this comment

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

A call to super.isLoggable(record) does this null check, and it also checks whether the LogRecord has an appropriate level and whether it satisfies any filter. In practice, the level check is handled by hudson.logging.LogRecorder.Target#matches and subclasses are unlikely to implement a filter, but calling super.isLoggable(record) here results in a slight deduplication of code and makes this subclass of Handler consistent with the subclasses of Handler provided by the Java Platform, so I think this is worth doing.

Suggested change
if (record == null) {
return;
}
if (!super.isLoggable(record)) {
return;
}

Copy link
Member Author

Choose a reason for hiding this comment

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

I will have to double-check, but I think this is what we do not want to do because this would prevent custom fine loggers from getting anything. Regular handlers either print a message to a sink or do not; handlers which collect all messages need to behave differently. https://github.com/jenkinsci/support-core-plugin/blob/7e75fdc7e9af0abe0d7d659a3e6e591c3451288f/src/main/java/com/cloudbees/jenkins/support/SupportLogHandler.java#L128-L135

Copy link
Member

Choose a reason for hiding this comment

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

This would prevent custom fine loggers from getting anything

I do not see how it could because we never mutate java.util.logging.Handler#logLevel from its default value of ALL in RingBufferLogHandler. Like I wrote earlier, I do not think there is a difference in practice, but I think using the built-in method better adheres to the parent class's extensible design just in case a theoretical subclass of RingBufferLogHandler wanted to use a custom level or filter.

Copy link
Member Author

Choose a reason for hiding this comment

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

It appears to work. Still, I would rather not do it here because

  • I am not entirely confident it is correct.
  • It is not much related to the rest of the change. (I merely added the null check after noticing that tooMuchRecordsShouldNotCrashHandler was not testing anything.)

Copy link
Member Author

Choose a reason for hiding this comment

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

a theoretical subclass of RingBufferLogHandler

I would rather just make it final than consider such possibilities.

Copy link
Member

Choose a reason for hiding this comment

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

I would rather just make it final than consider such possibilities.

I am OK with making it final.

core/src/main/java/hudson/util/RingBufferLogHandler.java Outdated Show resolved Hide resolved
core/src/main/java/hudson/util/RingBufferLogHandler.java Outdated Show resolved Hide resolved
core/src/main/java/hudson/util/RingBufferLogHandler.java Outdated Show resolved Hide resolved
@jglick
Copy link
Member Author

jglick commented Jun 10, 2022

we should run BOM/PCT on this

Yeah, would not hurt. Pretested the known relevant issue—see jenkinsci/support-core-plugin#376.

@jglick jglick marked this pull request as draft June 12, 2022 12:29
@jglick
Copy link
Member Author

jglick commented Jun 12, 2022

My timebox on this issue is expiring. Considering throwing it all out (just keeping the reversion parts) and instead avoiding large record parameters on a case-by-case basis.

@jglick
Copy link
Member Author

jglick commented Jun 28, 2022

Seems I had run into a leak with LogRecord.parameters years ago, acc. to a comment in jenkinsci/workflow-cps-plugin#41.

@jglick jglick changed the title [JENKINS-68417] Eagerly format LogRecord rather than holding SoftReferences [JENKINS-68417] Revert LogRecord tricks Jun 28, 2022
@jglick jglick marked this pull request as ready for review June 28, 2022 21:14
@timja timja requested a review from basil June 28, 2022 21:23
@jglick jglick requested a review from a team June 30, 2022 11:42
Copy link
Member

@basil basil left a comment

Choose a reason for hiding this comment

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

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback. Please see the merge process documentation for more information about the merge process. Thanks!

@basil basil added regression-fix Pull request that fixes a regression in one of the previous Jenkins releases ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback labels Jul 5, 2022
@timja timja merged commit 75b4b31 into jenkinsci:master Jul 6, 2022
@jglick jglick deleted the LogRecord-JENKINS-68417 branch July 6, 2022 12:40
NotMyFault pushed a commit to NotMyFault/jenkins that referenced this pull request Jul 23, 2022
Co-authored-by: Basil Crow <[email protected]>
(cherry picked from commit 75b4b31)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback regression-fix Pull request that fixes a regression in one of the previous Jenkins releases
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants