-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Limit overhead of capturing stacktrace in REST Client #42544
Conversation
@johnaohara any chance you could test if this improves things? I didn't have time to profile (I'm on PTO :)) |
/cc @brunobat (opentelemetry), @radcortez (opentelemetry) |
But we always capture the stack? Not only on errors? |
That's the only way to produce a meaningful stacktrace when an error occurs |
String className = stackFrame.getClassName(); | ||
return className.startsWith(RESTEASY_REACTIVE_PACKAGE) || className.contains(AUTOGENERATED_TAG); | ||
} | ||
}).limit(5).map(StackWalker.StackFrame::toStackTraceElement).toList(); |
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 5 lines enough?
this probably needs to be documented or add a config to keep the switch to the old behaviour.
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's fine for identifying which REST Client is causing the problem and where it was called from.
It's not a complete stacktrace, but the complete one is mostly useless except for the top frames
This is done by utilizing the StackWalker API and limiting the number of frames captured Closes: quarkusio#42508
Let's close this |
This is done by utilizing the StackWalker API
and limiting the number of frames captured