Skip to content

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:

xml
<plugin>
  <artifactId>maven-resources-plugin</artifactId>
  <version>3.2.0</version>
  <configuration>
    <useDefaultDelimiters>true</useDefaultDelimiters>
  </configuration>
</plugin>