Skip to end of banner
Go to start of banner

URL based view

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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)

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.
  •  
  • No labels