Searching for Configuration Problems

In some cases, the analysis and measurement of your project might not work as expected. Please check this page first; if you can not find a solution for your problem here, please file an issue in peass-ci-plugin.

Regression Test Selection does not Select my Test

Check the following problems:

Test Runs Longer Than Timeout

If your regression test selection contains output like

11:05:40.641 [org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution [#3]] DEBUG de.dagere.peass.execution.utils.TestExecutor:118 - Killing: de.hbt.fwr.entryways.EnterWaysCacheOrGetterIntegrationTest

it is very likely that your test just takes too much time (potentially if executed with instrumentation). Also, your test might contain the output --- Starting execution 1/1 --- but not the stopping output (if redirectToNull: false, showStart: true are set).

If this happens, consider

• increasing timeout in your pipeline configuration or
• setting onlyOneTraceRecoding to true.

Kieker Writer Queue

For every executed method, an entry is written to the Kieker writer queue and this entry is serialized afterwards. The writing might not finish on time due to too many method calls / too slow I/O.

If this error occurs, you will find something like

    10:44:01.116 [Test worker] DEBUG de.dagere.kopeme.kieker.KoPeMeKiekerSupport:104 - Queue size: 9999999
    10:44:02.333 [Test worker] DEBUG de.dagere.kopeme.kieker.KoPeMeKiekerSupport:104 - Queue size: 9999145
    10:44:03.386 [Test worker] DEBUG de.dagere.kopeme.kieker.KoPeMeKiekerSupport:104 - Queue size: 10000000
    10:44:04.500 [Test worker] DEBUG de.dagere.kopeme.kieker.KoPeMeKiekerSupport:104 - Queue size: 9999999
    10:44:05.865 [Test worker] DEBUG de.dagere.kopeme.kieker.KoPeMeKiekerSupport:104 - Queue size: 9999384
    10:44:07.167 [Test worker] DEBUG de.dagere.kopeme.kieker.KoPeMeKiekerSupport:112 - Final queue size: 9997446

in your tests log. If the Final queue size is above 0, it is very likely that traces are unreadable.

There are two possible solutions for this problem:

1. Use onlyOneCallRecording, so every method call will be recorded only once in the trace. While you loose some information, e.g. order of method calls, you gain the ability to analyse bit test cases without problems. This is the recommended solution.
2. If you want to obtain and analyze the whole trace, you can use three measures (which, unfortunately, can not guarantee that you can analyze the whole trace and might be RAM/hard-disk-space intensive):

• Consider increasing kiekerWaitTime or reducing the size of your test case.
• If your queue size hits the maximum queue size, consider increasing kiekerQueueSize.
• If your test only contains a few method calls that are repeated often, exclude them using excludeForTracing.

Traces are too big

If your traces are too big, the logs may contain output like:

java.lang.NegativeArraySizeException: -1283060894
	at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:904)
	at java.base/java.lang.StringCoding.encode(StringCoding.java:502)
	at java.base/java.lang.String.getBytes(String.java:981)
	at de.dagere.peass.dependency.traces.TraceWriter.writeTraces(TraceWriter.java:54)
	at de.dagere.peass.dependency.traces.TraceWriter.writeTrace(TraceWriter.java:38)
	at de.dagere.peass.dependency.traces.OneTraceGenerator.writeTrace(OneTraceGenerator.java:111)
	at de.dagere.peass.dependency.traces.OneTraceGenerator.generateTraceFiles(OneTraceGenerator.java:104)
	at de.dagere.peass.dependency.traces.OneTraceGenerator.generateTrace(OneTraceGenerator.java:59)
	at de.dagere.peass.dependency.reader.TraceViewGenerator.generateViews(TraceViewGenerator.java:58)
	at de.dagere.peass.dependency.reader.DependencyReader.generateInitialViews(DependencyReader.java:366)
	at de.dagere.peass.dependency.reader.DependencyReader.readInitialVersion(DependencyReader.java:354)

Since you reached the maximum size of a trace that can be contained in a String, the recommended fix is to set onlyOneCallRecording to true.

Process Count Cannot be Printed

Your logs may contain the following output:

java.lang.NumberFormatException: For input string: "bash: line 1: ps: command not found0"
	at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.base/java.lang.Integer.parseInt(Integer.java:652)
	at java.base/java.lang.Integer.parseInt(Integer.java:770)
	at de.dagere.peass.execution.processutils.ProcessBuilderHelper.getProcessCount(ProcessBuilderHelper.java:90)

This occurs if you are on a linux system and ps is not installed. Sometimes, repeating your workload might end up in starting too many subprocesses, which in turn might cause your system to run out of PIDs and therefore to crash. To help you debugging this problem, Peass prints the count of running processes before every run. If you do not need this feature, just ignore the message. If you need this feature, please install ps (e.g. sudo apt install procps).

Measurement Executes my Test Unsuccessfully

In order for measurement to be executable correctly, Peass needs a repeatable workload. By default, Peass executes @BeforeClass / @BeforeAll once, then executes @Before, your test case, @After (repeated), and then once @AfterClass / @AfterAll. If you want to execute @BeforeClass / @BeforeAll / @AfterClass / @AfterAll also repeated, set executeBeforeClassInMeasurement to true.

Too Many Used PIDs

The operating system limits the count of process ids that can be used. If your test processes spawn subprocesses that are not cleaned up, this might result in the system failing to start new processes. This in term will harm the stability of your system and make performance measurement results unusable. If you see this problem, try to increase the count of usable PIDs using e.g. sysctl -w kernel.pid_max=4194303.