Teamscale Java Profiler - Troubleshooting
In case you encounter a problem during setting up the Teamscale Java Profiler, this troubleshooting guide might help you.
Automatic upload failed
If the produced coverage failed to be automatically uploaded, it is stored in the provided out
folder. The profiler will retry to upload the coverage upon restart with the originally provided configs (e.g. server url, user, etc.). The coverage will be stored until the upload succeeds.
My application fails to start after registering the profiler
Most likely, you provided invalid parameters to the profiler. Please check the profilers log file. If that does not exist, please check stdout of your application. If the profiler can't write its log file, it will report the errors on stdout.
Produced coverage files are huge
You're probably profiling and analyzing more code than necessary (e.g. third-party libraries, etc.). Make sure to set restrictive include/exclude patterns via the profilers options.
Enable debug logging to see what is being filtered out and fine-tune these patterns.
I do not have access to the class files
In that case simply don't specify a class-dir
option. The profiler will read the class files at runtime and save them to a temporary directory for later use.
Warning: "Ignoring duplicate, non-identical class file for class..."
The underlying JaCoCo coverage instrumentation tooling relies on fully qualified class names to uniquely identify classes. However, in practice, applications are often deployed with multiple versions of the same class. This can happen, e.g. if you use the same library in different versions in subprojects of your code.
At runtime, it is not deterministic, which of these versions will be loaded by the class loader. Thus, when trying to convert the recorded coverage back to covered source code lines, JaCoCo cannot determine which of the two versions was actually profiled.
By default, the profiler is configured to only log a warning in these cases and simply pick one of the versions at random. Thus, the reported coverage for such files may not be accurate and may even be totally unusable. It is thus desirable to fix these warnings by ensuring that only one version of each class is deployed with your application. This has to be fixed in your build process.
Be advised that coverage for all classes that produce this warning in the log may have inaccurate coverage values reported.
Please refer to this StackOverflow post and the JaCoCo FAQ for more information.
How to change the log level
If you want to enable debug logging, you can simply set the corresponding profiler option:
debug=true
Otherwise, you can set an appropriate logback logging configuration XML in the profiler options:
logging-config=/PATH/TO/logback-config.xml
You can find example logging configurations in the logging folder in the profiler installation directory.
How to see which files/folders are filtered due to the includes
and excludes
parameters
Set debug=true
. Warning: This may create a lot of log entries!
Error: "The application was shut down before a commit could be found", despite including a git.properties file in your jar/war/...
When using application servers, the git.properties
file in your jar/war/... might not be detected automatically, which results in an "The application was shut down before a commit could be found" error. To resolve the problem, try specifying git-properties-jar
explicitly.
How can I find my log files (in case Teamscale does not show logs)
The log file is written to the profiled process's temp directory in the subfolder teamscale-java-profiler*/logs
by default.
Examples:
- Linux:
/tmp/teamscale-java-profiler-2534-2465434652/logs
- Windows:
C:\Users\%Username%\AppData\Local\Temp\teamscale-java-profiler-2534-2465434652\logs
where%Username%
is the name of the user under which the profiled application is running
Note that defining -Djava.io.tmpdir
will change the temp directory that is being used.
If there is no log file at that location, it means the profiler didn't even start and you have not configured it correctly. Check your application's console output for error messages.
Maven: The git.properties only contains placeholder values
When trying to add custom properties to the git.properties
file, it might happen that the template git.properties
file is not correctly populated. To prevent that, you can explicitly add the maven-resource-plugin to your build section and set useDefaultDelimiters
to true
:
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>3.2.0</version>
<configuration>
<useDefaultDelimiters>true</useDefaultDelimiters>
</configuration>
</plugin>