-
Notifications
You must be signed in to change notification settings - Fork 327
Avoid setting request attributes to reduce allocations #316
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
Avoid setting request attributes to reduce allocations #316
Conversation
Adding a request attribute creates a new HashMap$Node which allocates 32b - Only set transaction request attribute when startAsync is called - Set excluded as ThreadLocal as opposed to request attribute
| if (tracer == null) { | ||
| return; | ||
| } | ||
| excluded.set(Boolean.FALSE); |
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 for the sake of accurate state management, this should be done only when transaction != null.
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.
The transaction is null for excluded requests which is the exact case where we do want to set excluded back to the initial value. We could set it to false only if it's true or if transaction is null but I think it's simpler and not necessarily slower to set it always to false, just to be sure we don't miss anything.
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.
In the case of nested service calls, you set the excluded to true in the outmost invocation, so you should reset it in the exit of the same method. I understand why transaction != null is not good though as you say.
So what I suggest is: if you DO care about the state being set and reset accurately in the case of nested calls, you can add a local boolean variable that says whether this specific service method was the one changing the state or not. However, this is not super important I assume, so I am fine with whatever you decide.
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.
In the case of nested service calls, you set the excluded to true in the outmost invocation, so you should reset it in the exit of the same method.
I think it's just fine to set it to false in all nested filters and servlets. If it has already been reset to false, resetting it again does not change the state.
apm-agent-plugins/apm-servlet-plugin/src/main/java/co/elastic/apm/servlet/ServletApiAdvice.java
Outdated
Show resolved
Hide resolved
Codecov Report
@@ Coverage Diff @@
## master #316 +/- ##
===========================================
- Coverage 72.44% 72.14% -0.3%
+ Complexity 1195 1190 -5
===========================================
Files 131 131
Lines 4478 4484 +6
Branches 456 459 +3
===========================================
- Hits 3244 3235 -9
- Misses 1025 1038 +13
- Partials 209 211 +2
Continue to review full report at Codecov.
|
Adding a request attribute creates a new HashMap$Node which allocates 32b