-
-
Notifications
You must be signed in to change notification settings - Fork 8.8k
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
Conversation
} | ||
} | ||
synchronized (this) { | ||
int len = records.length; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hide whitespace in diff
…gRecord-JENKINS-68417
…reformatting on agents (jenkinsci#4912)
…in CI, not locally, but anyway Javadoc says a `null` `LogRecord` is permitted, and test should not bypass the interesting logic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (record == null) { | ||
return; | ||
} |
There was a problem hiding this comment.
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.
if (record == null) { | |
return; | |
} | |
if (!super.isLoggable(record)) { | |
return; | |
} |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
.
Yeah, would not hurt. Pretested the known relevant issue—see jenkinsci/support-core-plugin#376. |
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. |
…gRecord-JENKINS-68417
Seems I had run into a leak with |
LogRecord
rather than holding SoftReference
sLogRecord
tricks
There was a problem hiding this 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!
Co-authored-by: Basil Crow <[email protected]> (cherry picked from commit 75b4b31)
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 (jenkinsci/workflow-cps-plugin#557 seems to suffice.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.Proposed changelog entries
Maintainer checklist
Before the changes are marked as
ready-for-merge
:Proposed changelog entries
are accurate, human-readable, and in the imperative moodupgrade-guide-needed
label is set and there is aProposed upgrade guidelines
section in the PR title. (example)lts-candidate
to be considered (see query).