-
Notifications
You must be signed in to change notification settings - Fork 7
Item 7554: part 2 of log4jupgrade #1423
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
Conversation
|
|
||
| private void logJobMessage(LogEvent logEvent, @Nullable Throwable t) | ||
| { | ||
| if (logEvent.getLevel().compareTo(Level.DEBUG) == 0) |
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.
Can these use equals() instead of compareTo()?
And while we seldom use it, this is missing the TRACE level
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.
Should I add the trace level (It wasn't there earlier.)? Are there pipeline jobs that have the trace logging ?
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.
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.
OK, but let's make the new code better than the old. :)
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 doubt anyone's using trace now (since it doesn't work, apparently), but let's support it. I added trace level logging for some of the recent ODBC work, so I think there are legit use cases within our codebase
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.
sounds good, added it.
| LogEvent[] events = SessionAppender.getLoggingEvents(getViewContext().getRequest()); | ||
| ArrayList<Map<String, Object>> list = new ArrayList<>(events.length); | ||
| for (LogEvent e : events) | ||
| Map<LogEvent, String> events = SessionAppender.getLoggingEvents(getViewContext().getRequest()); |
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.
@labkey-martyp if you haven't already looked at this, can you make sure that it doesn't break the ETL logging scenario that you recently worked on?
labkey-jeckels
left a comment
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.
Looks good, but let's wait for Marty confirm on the JS console logging for the ETL scenario if you haven't already connected
| public void writeToFile(File file) | ||
| { | ||
| // Make sure that we try to mount the drive (if needed) before using the file | ||
| NetworkDrive.exists(file); |
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.
Since we only have a single use case, I recommend having the constructor open the BufferedWriter, adding a close() method, and calling it after all of the write() calls are done. That will make it so that you don't have to keep opening and closing the file for every line that gets written
labkey-martyp
left a comment
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.
Sorry, my delay getting to this probably got your branches out of sync with develop. I'm having difficulty getting this to build and looks like its not building on TC. Let me know if I can be any help fixing the build, but assume you can do it a lot quicker for this branch.
| @Plugin(name = "SessionAppender", category = Core.CATEGORY_NAME, elementType = Appender.ELEMENT_TYPE, printObject = true) | ||
| public class SessionAppender extends AbstractAppender | ||
| { | ||
| private static ThreadLocal<WeakHashMap<LogEvent, String>> _eventIds = new ThreadLocal<>(); |
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.
Is this being used?
| final String key; | ||
| boolean on; | ||
| final List<LogEvent> list = new LinkedList<>(); | ||
| final Map<LogEvent, String> eventIdMap = new WeakHashMap<>(); |
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 think this should probably be a ConcurrentReferenceHashMap. These can be accessed from multiple threads, so that will at least make the map operations thread safe. See appenderInfos implementation of that map type
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.
Possibly something like this? Still not great to just randomly remove index(0) but not sure how to get the eldest entry without using a LinkedHashMap, which does not have a weak reference option.
| final Map<LogEvent, String> eventIdMap = new WeakHashMap<>(); | |
| final Map<LogEvent, String> eventIdMap = new ConcurrentReferenceHashMap<>(16, ConcurrentReferenceHashMap.ReferenceType.WEAK) | |
| { | |
| @Override | |
| public String put(LogEvent key, String value) | |
| { | |
| // Safeguard against runaway size. ConcurrentReferenceHashMap does not have removeEldestEntry so have | |
| // to randomly remove an entry | |
| if (size() > 1000) | |
| remove(0); | |
| return super.put(key, value); | |
| } | |
| }; |
| info.eventIdMap.put(event, String.valueOf(++info.eventId)); | ||
| if (info.eventIdMap.size() > 1000) | ||
| info.eventIdMap.remove(0); |
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 is something I should have fixed, but would probably be safer to override the put() function of that map with this check.
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.
See suggestion above

Rationale
This is part two of log4j upgrade work, includes changes to custom appenders, event id handling for server javascript console and admin logging UI changes
Related Pull Requests