This requirement is related to this ticket INSPECTIT-439
Often inspectIT is used to analyse webbased applications. In order to easily analyse these applications invocation sequences are put to the HttpServlet's doGet and doPost method or to some doFilter methods of some Filter. Usually different use cases (e.g. different URLs) are then handled by the same entry point and thus makes the analysis of one certain Usecase (URL) very difficult. Currently the only way is to capture the URL as a parameter (but this also only works for some certain situations and is not portable).
Thus we need to have a way to capture the URL and provide an aggregation of all invocations that are done for the same URL (think of it as a timer view where we do not aggregate on the method the timer was invoked but on the URL of the invocation sequence). We can directly reuse all navigational possibilities and thus easily navigate to all invocation sequences of a given URL entry point and thus start the detailed analysis.
Analysis
- 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)