The piece I'd like to avoid is ThrowableProxy.loadClass invocations, which can be expensive depending on the ClassLoader implementation. The ThrowablePatternConverter implementations all fall back to the default implementation which operates directly on a Throwable rather than the proxy object.
I would prefer to make ThrowableProxy work better rather than disabling it entirely, which would open the flood gates for issues with the Jackson and Serializable layouts, though the counterargument is that without loading classes, there is no additional information provided by ThrowableProxy over a Throwable. I will take a look at flagging ThrowableProxy class loading instead of disabling ThrowableProxy entirely when I have a moment. Thanks, -ck On Thu, Aug 9, 2018 at 1:36 AM, Ralph Goers <[email protected]> wrote: > What is the purpose of disabling ThrowableProxy? All the throwable pattern > converters rely on it. > > Ralph > >> On Aug 8, 2018, at 8:34 AM, Carter Kozak <[email protected]> wrote: >> >> I'm curious what you would think of a system property to disable >> ThrowableProxy creation? >> My initial preference was to avoid this type of flag and make the >> common case cleaner, however >> without providing a mechanism to disable the functionality that >> differentiates it from Throwable >> I'm not sure that's feasible. >> >> An alternative approach may be to allow custom implementations of the >> logic surrounding >> ThrowableProxy.toCacheEntry which could potentially disable classloader >> lookups, >> or implement something like the request in github pull/195. This extension >> point >> would make ThrowableProxy refactors significantly more difficult in the >> future. >> >> -ck >> >> On Tue, Aug 7, 2018 at 11:10 PM, Carter Kozak <[email protected]> wrote: >>> My guess is that StackWalker provides additional information beyond >>> the array of classes >>> supplied by the SecurityManager, though I've not done a thorough analysis >>> yet. >>> >>> A quick targeted benchmark of our current implementations: >>> >>> Benchmark Mode Cnt >>> Score Error Units >>> StackTraceBenchmark.defaultJava8 thrpt 3 113965.921 ± >>> 119706.986 ops/s >>> StackTraceBenchmark.securityManager thrpt 3 788004.237 ± 82578.567 >>> ops/s >>> StackTraceBenchmark.stackWalker thrpt 3 182902.031 ± >>> 39018.395 ops/s >>> >>> >>> -ck >>> >>> On Tue, Aug 7, 2018 at 7:20 PM, Ralph Goers <[email protected]> >>> wrote: >>>> I have to wonder why using the security manager is faster than using >>>> StackWalker. StackWalker was created just for this purpose. Is the way it >>>> is implemented the problem? >>>> >>>> Ralph >>>> >>>> >>>>> On Aug 7, 2018, at 1:34 PM, cakofony <[email protected]> wrote: >>>>> >>>>> GitHub user cakofony opened a pull request: >>>>> >>>>> https://github.com/apache/logging-log4j2/pull/202 >>>>> >>>>> [LOG4J2-2391] Improve ThrowableProxy performace on java 9+ >>>>> >>>>> Share the SecurityManager implementation of getCurrentStackTrace >>>>> with the java 9 implementation. >>>>> >>>>> You can merge this pull request into a Git repository by running: >>>>> >>>>> $ git pull https://github.com/cakofony/logging-log4j2 >>>>> java9_getcurrentstacktrace >>>>> >>>>> Alternatively you can review and apply these changes as the patch at: >>>>> >>>>> https://github.com/apache/logging-log4j2/pull/202.patch >>>>> >>>>> To close this pull request, make a commit to your master/trunk branch >>>>> with (at least) the following in the commit message: >>>>> >>>>> This closes #202 >>>>> >>>>> ---- >>>>> commit 52bf8569e8e9881d0999156c31d99b99f28e6e73 >>>>> Author: Carter Kozak <ckozak@...> >>>>> Date: 2018-08-07T20:27:10Z >>>>> >>>>> [LOG4J2-2391] Improve ThrowableProxy performace on java 9+ >>>>> >>>>> Share the SecurityManager implementation of getCurrentStackTrace >>>>> with the java 9 implementation. >>>>> >>>>> ---- >>>>> >>>>> >>>>> --- >>>>> >>>> >>>> >> > >
