[
https://issues.apache.org/jira/browse/LOG4J2-2899?focusedWorklogId=462040&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-462040
]
ASF GitHub Bot logged work on LOG4J2-2899:
------------------------------------------
Author: ASF GitHub Bot
Created on: 22/Jul/20 12:47
Start Date: 22/Jul/20 12:47
Worklog Time Spent: 10m
Work Description: carterkozak commented on pull request #390:
URL: https://github.com/apache/logging-log4j2/pull/390#issuecomment-662432635
> I don't think it can be guaranteed that the methods will always be called
on the same thread
It can't be guaranteed that the original thread is still around or has the
same name either, and it's expensive to look up even if it is (where the cost
scales with total live threads). This becomes a question of risk tolerance and
computational cost.
I can keep the fallback around, I think the initial current-thread-check
will handle most cases, I imagine most log4j1.2 shim users aren't using
asynchronous components.
It's probably a good idea to replace the Thread reference with `threadId`
and `threadPriority` fields to avoid holding thread references if the event
sits in a queue for a while.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 462040)
Time Spent: 50m (was: 40m)
> LogEventWrapper.getThread only works on the first invocation
> ------------------------------------------------------------
>
> Key: LOG4J2-2899
> URL: https://issues.apache.org/jira/browse/LOG4J2-2899
> Project: Log4j 2
> Issue Type: Bug
> Components: log4j 1.2 emulation
> Affects Versions: 2.13.3
> Reporter: Carter Kozak
> Assignee: Carter Kozak
> Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> LogEventWrapper.getThread attempts to memoize the thread value but returns
> null if the thread field is already set where it should return the field
> value.
>
> Additionally the thread is discovered using Thread.getAllStackTraces which is
> an expensive operation. In most cases it should be sufficient to check only
> the current thread, if the getThread method is called from another thread
> there's no guarantee that the original thread still uses the same name, or
> that it still exists.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
