-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Feature/filter metrics v3.2 #1118
Feature/filter metrics v3.2 #1118
Conversation
52503d8
to
90f5816
Compare
This looks like an interesting addition, could you explain your use case? Do you have several filters which take a lot of time to process? Or do you want to measure Jersey's overhead along with the method? |
Sure! I'm working on some services related to handling of case folders for the Norwegian Tax Authority. This involves some rather complex data structures that can contain highly sensitive information in several places. |
Was that explanation enough? Is there anything else that we can do to progress on this feature? |
I will look at it more one more time tomorrow and if it's OK will make a new 3.2.5 release. |
Thank you very much for the contribution! The feature looks very useful and the implementation seems backward compatible and don't create a big performance penalty. |
* Refactor * Let user specify clock for @timed * Time request and response filtering
I've decided to go with this change only for 4.0.0 and keep the 3.2 branch only for bugfixes. |
This adds support for measuring time for the entire request processing, and the request and response filtering steps, in addition to the current measurement of the time used by the request method itself. In addition, support is added for letting users specify the clock to be used.
No extra metrics are added for methods with @timed annotations that specify an explicit name, as it's not really clear what those extra metrics should be named, and it seems wrong to add attributes to the @timed annotation for jersey-specific concepts. Ideas for how to add the extra metrics for explicitly named methods welcome!
Corresponding PR for master: #1119