Skip to content

Conversation

@labkey-ankurj
Copy link
Contributor

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


private void logJobMessage(LogEvent logEvent, @Nullable Throwable t)
{
if (logEvent.getLevel().compareTo(Level.DEBUG) == 0)
Copy link
Contributor

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

Copy link
Contributor Author

@labkey-ankurj labkey-ankurj Jul 22, 2020

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 ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here is old code in Pipeline.java
Screen Shot 2020-07-22 at 3 00 18 PM

Copy link
Contributor

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. :)

Copy link
Contributor

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

Copy link
Contributor Author

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());
Copy link
Contributor

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?

Copy link
Contributor

@labkey-jeckels labkey-jeckels left a 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);
Copy link
Contributor

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

Copy link
Contributor

@labkey-martyp labkey-martyp left a 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<>();
Copy link
Contributor

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<>();
Copy link
Contributor

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

Copy link
Contributor

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.

Suggested change
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);
}
};

Comment on lines +110 to +112
info.eventIdMap.put(event, String.valueOf(++info.eventId));
if (info.eventIdMap.size() > 1000)
info.eventIdMap.remove(0);
Copy link
Contributor

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

See suggestion above

@labkey-ankurj labkey-ankurj merged commit deb307e into fb_log4J_upgrade Jul 27, 2020
@labkey-ankurj labkey-ankurj deleted the fb_log4J_upgrade_2 branch July 27, 2020 18:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants