...
- We need this information for all HTTP related methods
- We need this information for HTTP filters
- Only one HttpTimer should be available for one user request. It is not meaningful to have multiple HTTP Timer Datas (one per Filter) in a long chain of filters.
- HttpTimer is a specialized version of the common Timer that provides additional information about the HTTP Request.
- HttpTimer will be integrated in invocation sequences instead of common timers (that is, the HttpTimer will overwrite any existing Timer. Each Timer must check if an httpTimer is already added and only add itself if none is there)
- What information do we need
- URI
- Parameters and Attributes
- QueryString
- Headers to allow tagging from load testing tools?
- anything else?
A "parameter" is a form field name/value pair passed from the HTML side of the world. Its value is a String.
An "attribute" is a Java object name/value pair passed only through the internal JavaServer processes. (I.e. it can come from a JSP or servlet but not an HTML page.) Its value is an Object.
Design
- Filters and HttpServlets are always within a chain. That means that at the topmost level there are no two HttpTimers. Thus we can threadlocally increase the number of HttpTimers and only for the first one add a real HttpTimer object, every other one just increases/decreases the count (at start and end). Thus we know when we reach the first one again and then remove the thread local information again. By this design we ensure that we have only one HttpTimer per User Request.
- The HttpSensor is put on all Filter classes and all Servlet classes. In addition, the parameter that represents the ServletRequest (the signature does not provide HttpServletRequest) is provided to the sensor.
- We are only interested in URL information and thus will check if the given concrete realisation of the ServletRequest parameter is indeed also a realization of HttpServletRequest. If this is not the case, we do not do anything as it is not providing URL information. Else we get the information
Open
- How to deal with requests for resources (like images, css, etc).
- Remove them entirely (That means, do not send the invocation sequence and their timers) -> needs to be configurable
- Provide filtering on the URL View
- How to deal with parameters/querystring in the URL view
- Do not aggregate on them
- Aggregate on them in the URL view (-> provide a configuration)