This section describes the various techniques that are available to troubelshoot InfraRED for both the Load Time Weaving(LTW, as detailed in the Installation page) and the Compile Time Weaving(CTW, as detailed in the Ant Task page).
The InfraRED version information gets displayed on the console when the instrumented application gets deployed. This is a necessary (though not sufficient) indicator to the successful setting up of the various server paths. This message is applicable to both the aop weaving mechanisms,viz, load time weaving as detailed in the Installation page and Ant Task page A sample version information message is given below :
********************************************* * InfraRED version XX-VERSION * * Configured logging system from file:/D:/infrared-home/infrared-log4j.xml *********************************************
If the instrumented application makes use of the Sun 1.4 JVM and the Load Time aop Weaving mechanism, then :
AspectWerkz - INFO - Pre-processor net.sf.infrared.weaverhook.ClassPreProcessorAdaptor loaded and initialized
AspectWerkz - INFO - Pre-processor org.codehaus.aspectwerkz.transform.AspectWerkzPreProcessor loaded and initialized
If the changes to the application as mentioned in
Installation page were applied correctly, and if the
infrared.print.applications is set to true (using -D JVM flag),
you should see the following message on the console(System.out) when the
[InfraRED] Created MonitorFacade for your-app, instance your-host-name, with config MonitorConfig[file:/D:/your-app-home/WEB-INF/classes/infrared-agent.properties]
The second line above indicates that InfraRED has successfully identified your-app application and would be monitoring it. The configuration file for this application is at D:/your-app-home/WEB-INF/classes/infrared-agent.properties. The first line is always printed and should not be taken as a sign of your application being sucessfully identifed by InfraRED.
InfraRED uses log4j for logging. It ships with a modified log4j version and does not interfere with the normal logging of the application.
To enable logging in InfraRED,
The format of the infrared-log4j.xml file is same as the regular log4j.xml file,
except that all references to classes in package
should be replaced with
net.sf.infrared.org.apache.log4j. A sample
infrared-log4j.xml is given below:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> <log4j:configuration debug="false"> <appender name="FILE" class="net.sf.infrared.org.apache.log4j.FileAppender"> <param name="file" value="./infrared.log"/> <layout class="net.sf.infrared.org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="[%c] - %m%n"/> </layout> </appender> <appender name="CONSOLE" class="net.sf.infrared.org.apache.log4j.ConsoleAppender"> <layout class="net.sf.infrared.org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="[%t %c] - %m%n"/> </layout> </appender> <category name="net.sf.infrared.agent.transport" additivity="false"> <priority value="DEBUG"/> <appender-ref ref="FILE"/> </category> <category name="net.sf.infrared.agent.health" additivity="false"> <priority value="DEBUG"/> <appender-ref ref="CONSOLE"/> </category> <root> <priority value="FATAL"/> <appender-ref ref="FILE"/> </root> </log4j:configuration>
Notice how all packages start with
If the system property
infrared.debug (specified typically
using -D JVM flag) is turned off (i.e its value is "false"),
InfraRED will not log any debug messages even if the log4j configuration
specifies debug level for the category. If the system property
is turned on (i.e. its value is "true"), InfraRED will log debug
message iff the category has log level DEBUG or more verbose.
The default value of this system property is false.
Two log categories are particularly important
net.sf.infrared.agent.transport.impl.SocketWriteris used to log if InfraRED is able to collect data in the application and send it across the GUI. If some data is collected and send to the GUI, you would be seeing logs like:
[net.sf.infrared.agent.transport.impl.SocketWriter] - SocketWriter (address = localhost/127.0.0.1, port = 7777 connected) - Wrote stats
net.sf.infrared.agent.healthis used to print information on how much data is collected. Sometimes you would think that InfraRED is all set up correctly, but no data shows up on the GUI. In those cases you should enable this log level - it helps identify whether data is not showing up because of all executions getting pruned. A sample log entry would look like:
[net.sf.infrared.agent.health] - Agent collected stats for operation that started at Tue Dec 13 07:35:53 GMT 2005 and ended at Tue Dec 13 07:35:53 GMT 2005. Tracked 10 and ignored 1
In general, InfraRED generates lots of logs in DEBUG mode, so it should be only be enabled when you run into issues.
To capture JDBC statistics, InfraRED it wraps driver-provided implementations of java.sql interfaces with its own (in the package net.sf.infrared.aspects.jdbc.p6spy).
This is fine in most cases, because most often the client code would use only the java.sql interfaces. But when using some drivers, one might need to cast to driver-specific interfaces. For instance, when inserting LOBs using Oracle drivers, one might need to cast to Oracle-specific interfaces.
As a solution, we provide a newer technique to collect JDBC statistics.
aop.xml in the
(whichever you are using), comment out the aspect net.sf.infrared.aspects.aj.JdbcAspect,
and uncomment the aspect net.sf.infrared.aspects.aj.NonWrappingJdbcAspect.
aop.xml in the
(whichever you are using; we assume that you would have already replaced the aop.xml
as mentioned in the installation page),
comment out the system infrared.system.jdbc,
and uncomment the system infrared.system.jdbc.nowrap.
As of the now, the feature where InfraRED records the PreparedStatement query parameter bindings is not available when JDBC is set up with this mode.
The instrumented application being monitored by Infrared throws a java.lang.Linkage error when both the instrumented application and the Infrared web application are deployed on the same server instance of Tomcat or JBoss. There are several ways to overcome this problem :