JLM remote tests failing on s390x openj9-openjdk8 #360

lumpfish · 2020-08-12T14:20:48Z

Test targets affected in this run https://ci.adoptopenjdk.net/job/Test_openjdk8_j9_sanity.system_s390x_linux_xl/205/console were:

21:17:57  FAILED test targets:
21:17:57  	TestJlmRemoteClassNoAuth_SE80_Linux_0
21:17:57  	TestJlmRemoteMemoryAuth_SE80_Linux_0
21:17:57  	TestJlmRemoteMemoryNoAuth_SE80_Linux_0
21:17:57  	TestJlmRemoteThreadNoAuth_SE80_Linux_0
21:17:57  	TestIBMJlmRemoteMemoryAuth_SE80_Linux_0
21:17:57  	TestIBMJlmRemoteMemoryNoAuth_SE80_Linux_0

Looking at the TestJlmRemoteClassNoAuth failure, this is what appears to be going on:

The output from the test step which fails is:

21:12:28  STF 20:12:27.564 - +------ Step 3 - Wait for processes to complete
21:12:28  STF 20:12:27.564 - | Wait for processes to meet expectations
21:12:28  STF 20:12:27.564 - |   Processes: [LT1, CL1]
21:12:28  STF 20:12:27.564 - |
21:12:28  STF 20:12:27.564 - Monitoring processes: CL1 LT1
21:12:28  CL1 j> 2020/08/10 20:12:27.617 ServerURL=service:jmx:rmi:///jndi/rmi://localhost:1234/jmxrmi
21:12:28  CL1 j> 2020/08/10 20:12:27.632 Trying to connect using JMXConnectorFactory
21:12:38  CL1 j> 2020/08/10 20:12:37.734 Monitored VM not ready at Aug 10, 2020 8:12:37 PM (attempt 0).
21:12:38  CL1 j> 2020/08/10 20:12:37.734 Wait 10 secs and trying again...
21:12:38  CL1 j> 2020/08/10 20:12:37.735 Trying to connect using JMXConnectorFactory
21:12:38  CL1 j> 2020/08/10 20:12:38.122 Connection established!
21:12:40  CL1 j> 2020/08/10 20:12:39.524 Starting to write data
21:14:27  STF 20:14:24.836 - **FAILED** Process LT1 has ended unexpectedly
21:14:27  STF 20:14:24.837 - Monitoring Report Summary:
21:14:27  STF 20:14:24.837 -   o Process CL1 is still running
21:14:27  STF 20:14:24.837 -   o Process LT1 has ended unexpectedly
21:14:27  STF 20:14:24.837 - Killing processes: CL1 LT1
21:14:27  STF 20:14:25.837 -   o Process CL1 killed
21:14:27  CL1 ..........j> 2020/08/10 20:14:25.002 Exiting as JVM we are connected to has finished
21:14:27  CL1 stderr Exception in thread "main" java.lang.AssertionError
21:14:27  CL1 stderr 	at org.junit.Assert.fail(Assert.java:86)
21:14:27  CL1 stderr 	at org.junit.Assert.fail(Assert.java:95)
21:14:27  CL1 stderr 	at net.openj9.test.jlm.remote.MemoryProfiler.getStatsViaProxy(MemoryProfiler.java:217)
21:14:27  CL1 stderr 	at net.openj9.test.jlm.remote.MemoryProfiler.main(MemoryProfiler.java:119)
21:14:27  STF 20:14:25.837 -   o Process LT1 is not running
21:14:27  **FAILED** at step 3 (Wait for processes to complete). Expected return value=0 Actual=1 at /home/jenkins/workspace/Test_openjdk8_j9_sanity.system_s390x_linux_xl/openjdk-tests/TKG/../TKG/test_output_15970884849145/TestIBMJlmRemoteMemoryNoAuth_SE80_Linux_0/20200810-201226-TestIBMJlmRemoteMemoryNoAuth/execute.pl line 157.
21:14:27  STF 20:14:25.971 - **FAILED** execute script failed. Expected return value=0 Actual=1

... and the reason:

A 'server' is started which runs a load test with 30 threads
A 'client' is started, which
a. connects to the server
b. enters a loop which should take 300 secs to complete:

			while (writesCnt < 30) {
				// Write out the threadData every 10 seconds
				if (secondsCnt == 10) {
					System.out.print(".");
					this.classData.writeData(classBean, compBean, runtimeBean, true);
					secondsCnt = 0;
					writesCnt++;
				}
				this.recordClassStats(runtimeBean, classBean);
				Thread.sleep(1000);
				secondsCnt++;
			}

If the server process terminates within this 300 seconds the connection to the client is broken, and this exception code is invoked in the client (the "Exiting as JVM we are connected to has finished" message is in the failing test output).

		} catch (UndeclaredThrowableException ue) {
			Throwable cause = ue.getCause();
			Class<ConnectException> connectExcept = ConnectException.class;
			Class<UnmarshalException> unmarshalExcept = UnmarshalException.class;

			if (connectExcept.isInstance(cause) || unmarshalExcept.isInstance(cause)) {
				
				// If the exception was caused by a Connect or Unmarshal
				// Exception, assume the monitored JVM has finished. 
				this.closeCSVFile();
				Message.logOut("Exiting as JVM we are connected to has finished");
				Assert.fail("Exiting as JVM we are connected to has finished");
			} else {
				Message.logOut(ue.getMessage());
				ue.printStackTrace();
				Assert.fail(ue.getMessage());
			}

The workload being run by the server completed in about 241 seconds. This is the test log from the server process.
19:50:30.042 - Starting thread. Suite=0 thread=0
19:50:30.044 - Starting thread. Suite=0 thread=1
19:50:30.044 - Starting thread. Suite=0 thread=2
19:50:30.044 - Starting thread. Suite=0 thread=3
19:50:30.044 - Starting thread. Suite=0 thread=4
19:50:30.044 - Starting thread. Suite=0 thread=5
19:50:30.044 - Starting thread. Suite=0 thread=6
19:50:30.044 - Starting thread. Suite=0 thread=7
19:50:30.044 - Starting thread. Suite=0 thread=8
19:50:30.045 - Starting thread. Suite=0 thread=9
19:50:30.045 - Starting thread. Suite=0 thread=10
19:50:30.045 - Starting thread. Suite=0 thread=11
19:50:30.045 - Starting thread. Suite=0 thread=12
19:50:30.045 - Starting thread. Suite=0 thread=13
19:50:30.045 - Starting thread. Suite=0 thread=14
19:50:30.045 - Starting thread. Suite=0 thread=15
19:50:30.045 - Starting thread. Suite=0 thread=16
19:50:30.046 - Starting thread. Suite=0 thread=17
19:50:30.046 - Starting thread. Suite=0 thread=18
19:50:30.046 - Starting thread. Suite=0 thread=19
19:50:30.046 - Starting thread. Suite=0 thread=20
19:50:30.046 - Starting thread. Suite=0 thread=21
19:50:30.046 - Starting thread. Suite=0 thread=22
19:50:30.046 - Starting thread. Suite=0 thread=23
19:50:30.046 - Starting thread. Suite=0 thread=24
19:50:30.046 - Starting thread. Suite=0 thread=25
19:50:30.047 - Starting thread. Suite=0 thread=26
19:50:30.047 - Starting thread. Suite=0 thread=27
19:50:30.047 - Starting thread. Suite=0 thread=28
19:50:30.047 - Starting thread. Suite=0 thread=29
19:50:50.046 - Completed 4.1%. Number of tests started=36949
19:51:10.081 - Completed 10.7%. Number of tests started=96540 (+59591)
19:51:30.084 - Completed 18.4%. Number of tests started=165692 (+69152)
19:51:50.131 - Completed 26.7%. Number of tests started=240584 (+74892)
19:52:10.046 - Completed 35.0%. Number of tests started=314749 (+74165)
19:52:30.042 - Completed 44.4%. Number of tests started=399346 (+84597)
19:52:50.075 - Completed 53.6%. Number of tests started=482697 (+83351)
19:53:10.121 - Completed 63.2%. Number of tests started=568508 (+85811)
19:53:30.094 - Completed 71.8%. Number of tests started=645908 (+77400)
19:53:50.110 - Completed 80.6%. Number of tests started=725710 (+79802)
19:54:10.049 - Completed 89.7%. Number of tests started=807530 (+81820)
19:54:30.095 - Completed 99.6%. Number of tests started=896148 (+88618)
19:54:31.038 - Thread completed. Suite=0 thread=8
19:54:31.039 - Thread completed. Suite=0 thread=24
19:54:31.039 - Thread completed. Suite=0 thread=18
19:54:31.039 - Thread completed. Suite=0 thread=13
19:54:31.040 - Thread completed. Suite=0 thread=29
19:54:31.040 - Thread completed. Suite=0 thread=15
19:54:31.041 - Thread completed. Suite=0 thread=17
19:54:31.041 - Thread completed. Suite=0 thread=4
19:54:31.041 - Thread completed. Suite=0 thread=28
19:54:31.041 - Thread completed. Suite=0 thread=12
19:54:31.041 - Thread completed. Suite=0 thread=22
19:54:31.041 - Thread completed. Suite=0 thread=9
19:54:31.042 - Thread completed. Suite=0 thread=14
19:54:31.043 - Thread completed. Suite=0 thread=2
19:54:31.043 - Thread completed. Suite=0 thread=19
19:54:31.043 - Thread completed. Suite=0 thread=3
19:54:31.043 - Thread completed. Suite=0 thread=20
19:54:31.044 - Thread completed. Suite=0 thread=1
19:54:31.045 - Thread completed. Suite=0 thread=26
19:54:31.045 - Thread completed. Suite=0 thread=7
19:54:31.045 - Thread completed. Suite=0 thread=5
19:54:31.046 - Thread completed. Suite=0 thread=11
19:54:31.047 - Thread completed. Suite=0 thread=0
19:54:31.048 - Thread completed. Suite=0 thread=25
19:54:31.039 - Thread completed. Suite=0 thread=16
19:54:31.048 - Thread completed. Suite=0 thread=27
19:54:31.049 - Thread completed. Suite=0 thread=10
19:54:31.050 - Thread completed. Suite=0 thread=6
19:54:31.053 - Thread completed. Suite=0 thread=21
19:54:31.055 - Thread completed. Suite=0 thread=23
19:54:31.104 - Load test completed
19:54:31.104 - Ran : 900000
19:54:31.104 - Passed : 900000
19:54:31.104 - Failed : 0
19:54:31.104 - Result : PASSED

So it seems that the workload being run by the server is not of sufficient size to guarantee that it will take >300 seconds in this s390x environment.

@Mesbah-Alam - does my analysis look reasonable?

The text was updated successfully, but these errors were encountered:

lumpfish · 2020-08-18T09:45:43Z

Looks like this may be the same as #246

lumpfish · 2020-09-03T15:57:40Z

So the 'server' process can be fixed by increasing the workload number of tests to run.

The 'client' process has this loop:

			while (writesCnt < 30) {
				// Write out the threadData every 10 seconds
				if (secondsCnt == 10) {
					Message.logOut("Writing report data ...");
					this.threadData.writeData(this.mbs, srvThrdName, stackDepth, true);
					Message.logOut(" done.");
					secondsCnt = 0;
					writesCnt++;
				}
				this.recordThreadStats(srvRuntimeName, srvThrdName);
				Thread.sleep(1000);
				secondsCnt++;
			}

The intent appears to be for this loop to take 5 minutes to complete (30 * 10 seconds). However, examining the job output shows this loop can take much longer than the anticipated 5 minutes owing to the amount of time it takes to write the test data:

On an aarch64 test, this gave the following output:

15:07:09  STF 14:07:08.741 - Monitoring processes: CL2 LT2
15:07:09  CL2 j> 2020/09/03 14:07:08.856 ServerURL=service:jmx:rmi:///jndi/rmi://localhost:1234/jmxrmi
15:07:09  CL2 j> 2020/09/03 14:07:08.886 Trying to connect using JMXConnectorFactory
15:07:19  CL2 j> 2020/09/03 14:07:19.100 Monitored VM not ready at Sep 3, 2020 2:07:19 PM (attempt 0).
15:07:19  CL2 j> 2020/09/03 14:07:19.101 Wait 10 secs and trying again...
15:07:19  CL2 j> 2020/09/03 14:07:19.101 Trying to connect using JMXConnectorFactory
15:07:20  CL2 j> 2020/09/03 14:07:19.705 Connection established!
15:07:32  CL2 j> 2020/09/03 14:07:32.240 Writing report data ...
15:07:44  CL2 j> 2020/09/03 14:07:44.415  done.
15:07:55  CL2 j> 2020/09/03 14:07:54.564 Writing report data ...
15:08:01  CL2 j> 2020/09/03 14:08:00.264  done.
15:08:11  CL2 j> 2020/09/03 14:08:10.424 Writing report data ...
15:08:16  CL2 j> 2020/09/03 14:08:15.932  done.
15:08:26  CL2 j> 2020/09/03 14:08:26.106 Writing report data ...
15:08:32  CL2 j> 2020/09/03 14:08:31.171  done.
15:08:42  CL2 j> 2020/09/03 14:08:41.394 Writing report data ...
15:08:46  CL2 j> 2020/09/03 14:08:46.432  done.
15:08:57  CL2 j> 2020/09/03 14:08:56.592 Writing report data ...
15:09:02  CL2 j> 2020/09/03 14:09:01.900  done.
15:09:12  CL2 j> 2020/09/03 14:09:12.072 Writing report data ...
15:09:19  CL2 j> 2020/09/03 14:09:17.729  done.
15:09:28  CL2 j> 2020/09/03 14:09:27.920 Writing report data ...
15:09:35  CL2 j> 2020/09/03 14:09:34.719  done.
15:09:45  CL2 j> 2020/09/03 14:09:44.946 Writing report data ...
15:09:52  CL2 j> 2020/09/03 14:09:50.871  done.
15:10:01  CL2 j> 2020/09/03 14:10:01.085 Writing report data ...
15:10:09  CL2 j> 2020/09/03 14:10:08.245  done.
15:10:20  CL2 j> 2020/09/03 14:10:18.804 Writing report data ...
15:10:25  CL2 j> 2020/09/03 14:10:24.204  done.
15:10:35  CL2 j> 2020/09/03 14:10:34.410 Writing report data ...
15:10:43  CL2 j> 2020/09/03 14:10:42.215  done.
15:10:53  CL2 j> 2020/09/03 14:10:52.634 Writing report data ...
15:11:03  CL2 j> 2020/09/03 14:11:01.325  done.
15:11:12  CL2 j> 2020/09/03 14:11:11.762 Writing report data ...
15:11:22  CL2 j> 2020/09/03 14:11:19.509  done.
15:11:30  CL2 j> 2020/09/03 14:11:29.641 Writing report data ...
15:11:38  CL2 j> 2020/09/03 14:11:36.993  done.
15:11:48  CL2 j> 2020/09/03 14:11:47.071 Writing report data ...
15:11:56  CL2 j> 2020/09/03 14:11:54.987  done.
15:12:05  CL2 j> 2020/09/03 14:12:05.254 Writing report data ...
15:12:14  CL2 j> 2020/09/03 14:12:12.905  done.
15:12:24  CL2 j> 2020/09/03 14:12:23.088 Writing report data ...
15:12:32  CL2 j> 2020/09/03 14:12:31.305  done.
15:12:42  CL2 j> 2020/09/03 14:12:41.773 Writing report data ...
15:12:52  CL2 j> 2020/09/03 14:12:50.935  done.
15:13:01  CL2 j> 2020/09/03 14:13:01.454 Writing report data ...
15:13:11  CL2 j> 2020/09/03 14:13:11.135  done.
15:13:22  CL2 j> 2020/09/03 14:13:21.584 Writing report data ...
15:13:34  CL2 j> 2020/09/03 14:13:31.925  done.
15:13:43  CL2 j> 2020/09/03 14:13:42.464 Writing report data ...
15:13:53  CL2 j> 2020/09/03 14:13:52.534  done.
15:14:03  CL2 j> 2020/09/03 14:14:02.706 Writing report data ...
15:14:13  CL2 j> 2020/09/03 14:14:10.885  done.
15:14:22  CL2 j> 2020/09/03 14:14:21.364 Writing report data ...
15:14:32  CL2 j> 2020/09/03 14:14:31.215  done.
15:14:42  CL2 j> 2020/09/03 14:14:41.934 Writing report data ...
15:14:52  CL2 j> 2020/09/03 14:14:51.495  done.
15:15:02  CL2 j> 2020/09/03 14:15:01.892 Writing report data ...
15:15:11  CL2 j> 2020/09/03 14:15:09.816  done.
15:15:11  STF 14:15:09.978 - **FAILED** Process LT2 has ended unexpectedly

So the 'Writing report data' in the run takes an average of about 8 secs, which would be (30 * 8 = 240 secs) for the whole test. Adding in the 300 one second sleeps gives a total run tom for the loop of 9 mins (300 + 240 secs) - a lot more than the expected 5 mins. In this test run the server process had been set to stop running new tests after 8 minutes, had therefore completed and as far as the test was concerned 'ended unexpectedly'.

The server side process currently has a time limit of 30 minutes, but the number of tests specified might mean it takes no where near that time to run them all. On the s390x machine it took about 5 minutes - on the aarch64 machine about 8 minutes. In both cases this was less than the amount of time the client process took to run, so the test failed.

Once the client side process has ended and the test has confirmed that the server side process is still running, the server process is killed, so it shouldn't matter if the workload (number of tests) specified would actually take longer than the 30 minutes time limit because the process will be killed as soon as the client side process completes.

lumpfish · 2020-09-08T16:48:35Z

I have create PR #361 and done a load of testing. With this change to the workload I have not seen any failures due to the client side or server side process timing out (basically the change ensures that the server side process will run for 30 minutes before ending of its own accord, but be cancelled by the test harness should the client side process terminate before then). The longest I saw the client side '5 minutes' take during testing was 15 mins.

The testing was done with this this playlist PR: adoptium/aqa-tests#1948, which came about as a result of running all tests on all platforms and implementations, and then excluding the tests which still fail. The end result is that if that PR is committed then some additional tests that those defined in the current jlm playlist.xml would be run.

If just the openjdk-systemtest PR is committed (not the openjdk-tests PR) all the tests defined in the current jlm playlist.xml pass.

These are the test runs:

jdk8

openj9

aarch64_linux https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3794/console
ppc64_aix https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3808/
ppc64le_linux https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3809/
s390x_linux https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3811/
x86-64_linux https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3799/console
x86-64_mac https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3810/
x86-64_windows https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3802/

JLM tests with security enabled fail on Windows #198 still applies

hotspot

eclipse-openj9/openj9#1566 applies everywhere

aarch32_linux:
aarch64_linux: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3833/
ppc64_aix: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3834/
ppc64le_linux: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3835/
x86-64_linux: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3832/
x86-64_mac: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3836/

jdk11

eclipse-openj9/openj9#1566 applies everywhere

aarch64_linux https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3818/
Failed with
eclipse-openj9/openj9#9046

ppc64_aix https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3814/
ppc64le_linux https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3815/
s390x_linux_xl https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3816/
x86-64_linux: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3803/
x86-64_mac https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3812/
x86-64_windows https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3804/

JLM tests with security enabled fail on Windows #198 still applies

hotspot

eclipse-openj9/openj9#1566 applies everywhere

aarch32_linux: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3821/
aarch64_linux: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3820/
ppc64_aix: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3822/
ppc64le_linux: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3823/
x86-64_linux: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3819/
x86-64_mac: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3824/
x86-64_windows: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/3825/

JLM tests with security enabled fail on Windows #198 still applies

Where there is a note to say that an issue is still present, those tests are excluded from the current jlm playlist.xml and also from the one in the playlist PR.

I think this leaves the following issues found by these tests still to be addressed:
eclipse-openj9/openj9#1566
eclipse-openj9/openj9#9046
#274
#198

lumpfish · 2020-09-08T16:53:33Z

@Mesbah-Alam , @smlambert - if you could perhaps take a look at the analysis and the PRs, see if what I've done looks like a reasonable first step to cleaning up these jlm failures?

Mesbah-Alam · 2020-09-08T17:36:40Z

The end result is that if that PR is committed then some additional tests that those defined in the current jlm playlist.xml would be run.

@lumpfish - could you please explain this a bit more? If we un-exclude all the jlm tests and run all of them with #361 , do we see all of them pass?

I think the final step of this clean up exercise would be to consolidate the excludes in the playlist and only have those excludes in place that are tied to issues not related to the current one (e.g. test timing out).

lumpfish · 2020-09-09T10:30:15Z

I'll try putting it differently:

If Adjust jlm load parameters #361 is committed, I believe that fixes the various issues which refer the the JLM remote test timing out, namely:
JLM remote tests failing on s390x openj9-openjdk8 #360
sanity.system assertion failure on x86-64_linux_xl #270
JlmRemote* failures #246
JLM remote tests fail on openjdk8-j9 ppc64le_linux #145
JTReg jdk11-m2 Failure: TestJlmRemoteMemoryAuth_0 eclipse-openj9/openj9#9046

According to the testing I've done all the non-openj9 specific tests tests currently defined in the jlm playlist.xml will then pass.

I actually did the testing with the playlist in PR Reinstate jlm tests aqa-tests#1948, which runs more tests than those defined in the current jlm playlist.xml, since I found that some which were excluded passed in my testing. I also 'tidied up' the playlist (basically removing complications due to some tests working on jdk9 but not later releases, by removing references to jdk9,which is no longer tested).
Any tests which still fail (for reasons not related to timing out) are still excluded by the playlist in Reinstate jlm tests aqa-tests#1948, namely:
java.lang.IllegalArgumentException: argument type mismatch received in JMX Bean test in Hotspot, but none in OpenJ9 eclipse-openj9/openj9#1566
JTReg jdk11-m2 Failure: TestJlmRemoteMemoryAuth_0 eclipse-openj9/openj9#9046
TestJlmRemoteMemoryNoAuth intermittently fails with 'Peak Usage used memory smaller than Current Usage used memory' #274
JLM tests with security enabled fail on Windows #198
Note that nothing has been done yet for the openj9 only jlm tests (which are in the https://github.com/lumpfish/openj9-systemtest repository, but executed via the same playlist). They probably need similar adjustments,but we can deal with those next.

Mesbah-Alam · 2020-09-09T14:00:13Z

I've approved #361

Note that nothing has been done yet for the openj9 only jlm tests (which are in the https://github.com/lumpfish/openj9-systemtest repository, but executed via the same playlist)

Should those changes be done before we merged adoptium/aqa-tests#1948 ?

lumpfish · 2020-09-09T15:10:59Z

Should those changes be done before we merged AdoptOpenJDK/openjdk-tests#1948 ?

I don't think that's necessary. There are no changes in the playlist for those tests so they'll continue to run as they are now. We may as well get the benefit for the non openj9 specific tests first (or find any new issues with the change!).

Mesbah-Alam · 2020-09-09T15:22:55Z

adoptium/aqa-tests#1948 is also approved. Please merge the two PRs. Thanks a lot!

lumpfish · 2020-10-14T13:11:49Z

Fixed by #361

karianna added the bug label Aug 14, 2020

lumpfish mentioned this issue Sep 8, 2020

JlmRemote* failures #246

Closed

Mesbah-Alam mentioned this issue Sep 9, 2020

Reinstate jlm tests adoptium/aqa-tests#1948

Merged

lumpfish mentioned this issue Sep 15, 2020

Adjust jlm load parameters #361

Merged

lumpfish closed this as completed Oct 14, 2020

karianna added this to the October 2020 milestone Oct 14, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

JLM remote tests failing on s390x openj9-openjdk8 #360

JLM remote tests failing on s390x openj9-openjdk8 #360

lumpfish commented Aug 12, 2020

lumpfish commented Aug 18, 2020

lumpfish commented Sep 3, 2020

lumpfish commented Sep 8, 2020 •

edited

Loading

lumpfish commented Sep 8, 2020

Mesbah-Alam commented Sep 8, 2020 •

edited

Loading

lumpfish commented Sep 9, 2020

Mesbah-Alam commented Sep 9, 2020

lumpfish commented Sep 9, 2020

Mesbah-Alam commented Sep 9, 2020 •

edited

Loading

lumpfish commented Oct 14, 2020

JLM remote tests failing on s390x openj9-openjdk8 #360

JLM remote tests failing on s390x openj9-openjdk8 #360

Comments

lumpfish commented Aug 12, 2020

lumpfish commented Aug 18, 2020

lumpfish commented Sep 3, 2020

lumpfish commented Sep 8, 2020 • edited Loading

lumpfish commented Sep 8, 2020

Mesbah-Alam commented Sep 8, 2020 • edited Loading

lumpfish commented Sep 9, 2020

Mesbah-Alam commented Sep 9, 2020

lumpfish commented Sep 9, 2020

Mesbah-Alam commented Sep 9, 2020 • edited Loading

lumpfish commented Oct 14, 2020

lumpfish commented Sep 8, 2020 •

edited

Loading

Mesbah-Alam commented Sep 8, 2020 •

edited

Loading

Mesbah-Alam commented Sep 9, 2020 •

edited

Loading