...
- 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?
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
...