Java Transactions Test

When a user initiates a transaction to a Java-based web application, the transaction typically travels via many Java components before completing execution and sending out a response to the user.

The key Java components have been briefly described below:

  • Filter: A filter is a program that runs on the server before the servlet or JSP page with which it is associated. All filters must implement javax.servlet.Filter. This interface comprises three methods: init, doFilter, and destroy.
  • Servlet: A servlet acts as an intermediary between the client and the server. As servlet modules run on the server, they can receive and respond to requests made by the client.  If a servlet is designed to handle HTTP requests, it is called an HTTP Servlet.
  • JSP: Java Server Pages are an extension to the Java servlet technology. A JSP is translated into Java servlet before being run, and it processes HTTP requests and generates responses like any servlet. Translation occurs the first time the application is run.
  • Struts: The Struts Framework is a standard for developing well-architected  Web applications. Based on the Model-View-Controller (MVC) design paradigm, it distinctly separates all three levels (Model, View, and Control).

A delay experienced by any of the aforesaid Java components can adversely impact the total response time of the transaction, thereby scarring the user experience with the web application. In addition, delays in JDBC connectivity and slowdowns in SQL query executions (if the application interacts with a database), bottlenecks in delivery of mails via the Java Mail API  (if used), and any slow method calls, can also cause insufferable damage to the 'user-perceived' health of a web application.

The challenge here for administrators is to not just isolate the slow transactions, but to also accurately identify where the transaction slowed down and why -  is it owing to inefficent JSPs? poorly written servlets or struts? poor or the lack of any JDBC connectivity to the database? long running queries? inefficient API calls? or delays in accessing the POJO methods? The eG JTM Monitor provides administrators with answers to these questions!

With the help of the Java Transactions test, the eG JTM Monitor traces the route a configured web transaction takes, and captures live the total responsiveness of the transaction and the response time of each Java component it visits en route. This way, the solution proactively detects transaction slowdowns, and also precisely points you to the Java components causing it - is it the Filters? JSPs? Servlets? Struts? JDBC? SQL query? Java Mail API? or the POJO? In addition to revealing where (i.e., at which Java component) a transaction slowed down, the solution also provides the following intelligent insights, on demand, making root-cause identification and resolution easier:

  1. A look at the methods that took too long to execute, thus leading you to those methods that may have contributed to the slowdown;
  2. Single-click access to each invocation of a chosen method, which provides pointers to when and where a method spent longer than desired;
  3. A quick glance at SQL queries and Java errors that may have impacted the responsiveness of the transaction;   

Using these interesting pointers provided by the eG JTM Monitor, administrators can diagnose the root-cause of transaction slowdowns within minutes, rapidly plug the holes, and thus ensure that their critical web applications perform at peak capacity at all times! 

Before attempting to monitor Java transactions using the eG JTM Monitor, the following configurations will have to be performed:

  1. In the <EG_INSTALL_DIR>\lib directory (on Windows; on Unix, this will be /opt/egurkha/lib) of the eG agent, you will find the following files:

    1. eg_jtm.jar
    2. aspectjrt.jar
    3. aspectjweaver.jar
    4. jtmConn.props
    5. jtmLogging.props
    6. jtmOther.props
  2. Login to the system hosting the Java application to be monitored.
  3. If the eG agent will be 'remotely monitoring' the target Java application (i.e., if the Java application is to be monitored in an 'agentless manner'), then, copy all the files mentioned above from the <EG_INSTALL_DIR>\lib directory (on Windows; on Unix, this will be /opt/egurkha/lib) of the eG agent to any location on the Java application host.

  4. Then, proceed to edit the start-up script of the Java application being monitored, and append the following lines to it:

    set JTM_HOME=<<PATH OF THE LOCAL FOLDER CONTAINING THE JAR FILES AND PROPERTY FILES LISTED ABOVE>>"
    -javaagent:%JTM_HOME%\aspectjweaver.jar"      
    "-DEG_JTM_HOME=%JTM_HOME%"

    Note that the above lines will change based on the operating system and the web/web application server being monitored.

    Then, add the eg_jtm.jar, aspectjrt.jar, and aspectjweaver.jar files to the classpath of the Java application being monitored.

    Finally, save the file. Once this is done, then, the next time the Java application starts, the eG JTM Monitor scans the web requests to the application for configured URL patterns. When a match is found, the eG JTM Monitor collects the desired metrics and stores them in memory.

    Then, every time the eG agent runs the Java Transactions test, the agent will poll the eG JTM Monitor (on the target application) for the required metrics, extract the same from the application's memory, and report them to the eG manager.  

  5. Next, edit the jtmConn.props file. You will find the following lines in the file:

    #Contains the connection properties of eGurkha Java Transaction Monitor
    JTM_Port=13631
    Designated_Agent=

    By default, the jtm_Port parameter is set to 13631. If the Java application being monitored listens on a different JTM port, then specify the same here. In this case, when managing a Java Application using the eG administrative interface, specify the JTM_Port that you set in the jtmConn.props file as the Port of the Java application.

    Also, against the Designated_Agent parameter, specify the IP address of the eG agent which will poll the eG JTM Monitor for metrics. If no IP address is provided here, then the eG JTM Monitor will treat the host from which the very first 'measure request' comes in as the Designated_Agent.

    Note:

    In case a specific Designated_Agent is not provided, and the eG JTM Monitor treats the host from which the very first 'measure request' comes in as the Designated_Agent, then if such a Designated_Agent is stopped or uninstalled for any reason, the eG JTM Monitor will wait for a maximum of 10 measure periods for that 'deemed' Designated_Agent to request for metrics. If no requests come in for 10 consecutive measure periods, then the eG JTM Monitor will begin responding to 'measure requests' coming in from any other eG agent.

  6. Finally, save the jtmConn.props file.

Then, proceed to configure the Java Transactions test as discussed in the Java Transactions Test page.