Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix SSL Test Failure due to client exiting too soon during remote compile #18393

Merged
merged 1 commit into from
Nov 8, 2023
Merged

Fix SSL Test Failure due to client exiting too soon during remote compile #18393

merged 1 commit into from
Nov 8, 2023

Conversation

SajinaKandy
Copy link
Contributor

@SajinaKandy SajinaKandy commented Nov 2, 2023 •
edited
Loading

Due to time delays between SSL context initialization at the server and and the client program exiting too soon, the SSL tests were failing. The failure happens due to:
Required condition was not found: [Output match: Connected to a server] As the client did not connect to the server as expected.

This fix will check the condition for the connection established with the server and compile synchronously.

Closes: ##18308

@SajinaKandy
Copy link
Contributor Author

@mpirvu Could you review the changes.

@SajinaKandy
Copy link
Contributor Author

The additional output lines will be printed as below:

When the verbose log contains the string:

 [OUT] start running script
 [OUT] Generate SSL certificates
 [OUT] Creating SSL certificates
 [OUT] Certificates generated
 [OUT] Starting /home/dev/bootjdk17/bin/jitserver -XX:JITServerPort=56631  -XX:JITServerSSLKey=key.pem -XX:JITServerSSLCert=cert.pem -Xjit:verbose={JITServer},vlog=sslVlog
 [OUT]  867500 pts/1    00:00:00 jitserver
 [OUT] JITSERVER EXISTS
 [OUT] Check sslVlog to verify SSL initialization at server
 [OUT]  867500 pts/1    00:00:00 jitserver
 [OUT] JITSERVER STILL EXISTS
 [OUT] Terminating /home/dev/bootjdk17/bin/jitserver -XX:JITServerPort=56631  -XX:JITServerSSLKey=key.pem -XX:JITServerSSLCert=cert.pem -Xjit:verbose={JITServer},vlog=sslVlog
 [OUT] finished script

When the verbose log does not contains the string:

 [OUT] start running script
 [OUT] Generate SSL certificates
 [OUT] Creating SSL certificates
 [OUT] Certificates generated
 [OUT] Starting /home/dev/bootjdk17/bin/jitserver -XX:JITServerPort=54175  -Xjit:verbose={JITServer},vlog=sslVlog 
 [OUT]  941359 pts/3    00:00:00 jitserver
 [OUT] JITSERVER EXISTS
 [OUT] Check sslVlog to verify SSL initialization at server
 [OUT] Waiting for SSL initialization at server
 [OUT] Waiting for SSL initialization at server
 [OUT] Waiting for SSL initialization at server
 [OUT] Waiting for SSL initialization at server
 [OUT] Waiting for SSL initialization at server
 [OUT] Server SSL initialization is taking more time than expected or there is some error

@mpirvu
Copy link
Contributor

mpirvu commented Nov 3, 2023

If the server has a mismatching key, then it will initialize the context, but the connection still fails.
We need to make sure that compilations pass through. To ensure this, we need to make compilations synchronous, so that the application threads wait for the compilations to be performed.

@SajinaKandy
Copy link
Contributor Author

@mpirvu If you are refering about the test case where Server initializes its SSL context with whatever keys and then a client tries to connect with a mis-matched key. Then in that test case, the connection to the server will fail. And hence no compilations will be performed at the server for the client.

We need to make sure that compilations pass through.

Didn't understand the objective of this.

So currently the SSL test cases(and the existing tests) only check for connection success or failure as expected based on the scenario we are testing.
Are you suggesting we add conditions for compilation success/failure too?

@mpirvu
Copy link
Contributor

mpirvu commented Nov 3, 2023

What happens in the following scenario:

  • The server start-up and initializes the security context with a mismatch key
  • The client start-up, initializes its security context, but it does not have to perform any compilations?

Is this test passing because it saw the server initializing the context?

@mpirvu
Copy link
Contributor

mpirvu commented Nov 3, 2023

We need to make sure that compilations pass through.

Didn't understand the objective of this.

Without a compilation attempt we cannot establish if the client can successfully connect to the server.

@mpirvu
Copy link
Contributor

mpirvu commented Nov 3, 2023

In the original test failure we see the following:

 [ERR]  (cold) Compiling sun/reflect/Reflection.getCallerClass()Ljava/lang/Class;  OrdinaryMethod j9m=000000000004FED8 remote t=0 compThreadID=0 memLimit=262144 KB freePhysicalMemory=4272 MB
 [ERR] #JITServer: SSL connection on socket 0xa, Version: TLSv1.3, Cipher: TLS_AES_256_GCM_SHA384
 [ERR] 
 [ERR] #JITServer: Client sending compReq seqNo=1 to server for method sun/reflect/Reflection.getCallerClass()Ljava/lang/Class; @ cold.
 [ERR] openjdk version "1.8.0_392-internal"
 [ERR] OpenJDK Runtime Environment (build 1.8.0_392-internal-_2023_10_17_07_09-b00)
 [ERR] Eclipse OpenJ9 VM (build master-b965447, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20231017_1556 (JIT enabled, AOT enabled)
 [ERR] OpenJ9   - b965447
 [ERR] OMR      - 16c71a7
 [ERR] JCL      - a341bc4 based on jdk8u392-b07)
 [ERR] #PERF:  Time spent in compilation thread =0 ms
 [ERR] #INFO:  Stopping compilation thread, vmThread pointer 0000000000026100, thread ID 3

So, the client connected to the server (#JITServer: SSL connection on socket 0xa, Version: TLSv1.3, Cipher: TLS_AES_256_GCM_SHA384) and then sent a compilation request, but then the short application from the client started to end before the compilation was performed.
In this case the line#JITServer: SSL connection on socket 0xa, Version: TLSv1.3, Cipher: TLS_AES_256_GCM_SHA384 tells us that a successful connection was established. However, if the client finishes before having time to request a compilation, we cannot know whether the client will connect successfully or not.

@mpirvu
Copy link
Contributor

mpirvu commented Nov 3, 2023

I ran some local tests:

  1. The server always prints "Successfully initialized SSL context" if SSL enabled. It doesn't mater if the client uses a compatible certificate or a mismatching one.
  2. The earliest moment the client knows it connected to the server is through this message: "SSL connection on socket" which happens at the beginning of a remote compilation attempt. If the certificate is incompatible, the message becomes: "Failed to SSL_connect"

So, one way to improve the test is to watch for one of these earlier messages at the client. This reduces the possibility of a test failing due to wrong reason but does not eliminate it: if the client does not have time to issue a compilation, there is no way to check whether the connection would be successful or not. Using a small count (e.g. count=1) increases the chances of the client issuing a compilation. Moreover, if the test sees that no compilation was issued by the client (those lines with "compiling"), then we should not fail the test because it was inconclusive.

@SajinaKandy
Copy link
Contributor Author

@mpirvu Thanks for the explanation. I agree to what you are saying.

During a successful SSL connection with correct certificates the client prints:

#JITServer: SSL connection on socket 0x5, Version: TLSv1.3, Cipher: TLS_AES_256_GCM_SHA384

#JITServer: Client sending compReq seqNo=1 to server for method java/lang/System.getSysPropBeforePropertiesInitialized(I)Ljava/lang/String; @ cold.
#JITServer: t=    20 Connected to a server (serverUID=2441547603666174188)

With mis-matched certificates:

40064D84B37F0000:error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1883:
#FAILURE:  JITServer::StreamFailure: Failed to SSL_connect for java/lang/System.getSysPropBeforePropertiesInitialized(I)Ljava/lang/String; @ cold
#JITServer: t=    10 Could not connect to a server. Next attempt in 2000 ms.
#JITServer: t=    10 Resetting activation policy to AGGRESSIVE because client has lost connection to server
#JITServer: compThreadID=0 JITServer StreamFailure: Generic stream failure

Hence in the existing tests we check for the string Connected to a server or Could not connect to a server (and/or JITServer::StreamFailure: Failed to SSL_connect)

As an addition we can introduce a -Xjit:count=1 at the client to improve the code so there is a better chance for the client to issue compilations. Does the option -XX:-JITServerLocalSyncCompiles help too ?

@SajinaKandy
Copy link
Contributor Author

Currently the tests are failing for the success scenario where the certificates are matching and the connection is expected to be successful.

The client side relevant logs during connection are:

(cold) Compiling java/lang/System.getSysPropBeforePropertiesInitialized(I)Ljava/lang/String;  OrdinaryMethod j9m=0000000000058850 remote t=0 compThreadID=0 memLimit=262144 KB freePhysicalMemory=9628 MB
#JITServer: SSL connection on socket 0x5, Version: TLSv1.3, Cipher: TLS_AES_256_GCM_SHA384

#JITServer: Client sending compReq seqNo=1 to server for method java/lang/System.getSysPropBeforePropertiesInitialized(I)Ljava/lang/String; @ cold.
#JITServer: t=    10 Connected to a server (serverUID=2441547603666174188)
#JITServer: Client successfully loaded method java/lang/System.getSysPropBeforePropertiesInitialized(I)Ljava/lang/String; @ cold following compilation request. [metaData=00007F6EB492E038, startPC=00007F6EB64D103C]
+ (cold) java/lang/System.getSysPropBeforePropertiesInitialized(I)Ljava/lang/String; @ 00007F6EB64D103C-00007F6EB64D1172 OrdinaryMethod - Q_SZ=32 Q_SZI=32 QW=33 j9m=0000000000058850 bcsz=3 JNI remote time=25372us mem=[region=256 system=2048]KB compThreadID=0 CpuLoad=543%(67%avg) JvmCpu=0% queueTime=25976us

At the server we can see:

#JITServer: SSL connection on socket 0x6, Version: TLSv1.3, Cipher: TLS_AES_256_GCM_SHA384

#JITServer: Server received request for stream 00007FC0A2D0ED60
#JITServer: t=2765010 A new client (clientUID=18053300465393758928) connected. Server allocated a new client session.
#JITServer: compThreadID=0 created clientSessionData=00007FC0206F6010 for clientUID=18053300465393758928 seqNo=1 (isCritical=1) (criticalSeqNo=0 lastProcessedCriticalReq=0)
#JITServer: compThreadID=0 will ask for address ranges of unloaded classes and CHTable for clientUID 18053300465393758928
#JITServer: compThreadID=0 will initialize CHTable for clientUID 18053300465393758928 size=19992
 (cold) Compiling java/lang/System.getSysPropBeforePropertiesInitialized(I)Ljava/lang/String;  OrdinaryMethod j9m=0000000000058850  t=2765061 compThreadID=0 memLimit=524288 KB freePhysicalMemory=9681 MB
+ (cold) java/lang/System.getSysPropBeforePropertiesInitialized(I)Ljava/lang/String; @ 00007FC092C0003C-00007FC092C00172 OrdinaryMethod - Q_SZ=0 Q_SZI=0 QW=0 j9m=0000000000058850 bcsz=3 JNI time=5182us mem=[region=704 system=16384]KB compThreadID=0 CpuLoad=769%(96%avg) JvmCpu=0% queueTime=54346us
#JITServer: compThreadID=0 has successfully compiled java/lang/System.getSysPropBeforePropertiesInitialized(I)Ljava/lang/String; memoryState=2

So accordingly do you think its good to check for JITServer: compThreadID=0 has successfully compiled as a required condition instead of the Connected to a server [specially good for the scenario which failed in the original issue]

@mpirvu
Copy link
Contributor

mpirvu commented Nov 3, 2023 •
edited
Loading

Does the option -XX:-JITServerLocalSyncCompiles help too

I don't this so. This option makes all synchronous compilations remote, but in the small test case you are using you should not see synchronous compilations.
This could could become useful if you used -Xjit:count=0 which makes all compilations synchronous.

@mpirvu
Copy link
Contributor

mpirvu commented Nov 3, 2023

So accordingly do you think its good to check for JITServer: compThreadID=0 has successfully compiled as a required condition instead of the Connected to a server [specially good for the scenario which failed in the original issue]

No. That message comes even later than the moment the connection is established.

The example you have earlier in comment #18393 (comment) should not have failed because the client has issued: "Connected to a server".

@SajinaKandy
Copy link
Contributor Author

The example you have earlier in comment #18393 (comment) should not have failed because the client has issued: "Connected to a server".

This is correct. The logs are from a successful connection case. I was trying to see what string I should use to make the test case test id="Test SSL success condition" succeed. Currently we have the following as success condition, this can be made a required condition:

            <output type="success" caseSensitive="no" regex="no">SSL connection on socket</output>

And convert the following from required to success

            <output type="required" caseSensitive="no" regex="no">Connected to a server</output>

If we change the code like above, then in that case we establish a successful connection with matching SSL certificates(on both sides) only when we match the string SSL connection on socket. We do not mandate the remote compilations as a success criteria for this test case in that case.

I think the -Xjit:count=1 could possibly help deal with the failure we are seeing now and then we can still keep the Connected to a server as a required condition too.

@mpirvu
Copy link
Contributor

mpirvu commented Nov 4, 2023

I think the -Xjit:count=1 could possibly help deal with the failure we are seeing now and then we can still keep the Connected to a server as a required condition too.

I disagree.
-Xjit:count=1 helps reducing the frequency of the false failures.
Similarly, looking at "SSL connection on socket" instead of "Connected to a server" helps too.
Having both at the same time reduces the probability of a false positive even more. Investigating why a test failed when in fact it passed wastes developer time.
I would be inclined to go all the way and use -Xjit:count=0 to make sure that the application cannot end before a connection attempt is made.

@SajinaKandy
Copy link
Contributor Author

@mpirvu I have changed the fix now. Please review the changes.

@mpirvu
Copy link
Contributor

mpirvu commented Nov 7, 2023

It may be better to add -XX:-JITServerLocalSyncCompiles too. count=0 makes all compilation synchronous and we want to make sure that such compilations are sent to the server to validate the connection.
There might be other heuristics too that keep some of the compilations local.

@SajinaKandy
Fix SSL Test Failure due to time delays in SSL initialization
5f6edc8 
Due to time delays between SSL context initialization at the server and
and the client program exiting too soon, the SSL tests were failing.
The failure happens due to:
Required condition was not found: [Output match: Connected to a server]
As the client did not connect to the server as expected.

This fix reads the jitserver verbose log to confirm if the SSL context
is initialized before starting the client.

Closes: #eclipse-openj9#18308
Signed-off-by: SajinaKandy <[email protected]>
@SajinaKandy SajinaKandy changed the title Fix SSL Test Failure due to time delays in SSL initialization Fix SSL Test Failure due to client exiting too soon during remote compile Nov 7, 2023
mpirvu
mpirvu approved these changes Nov 7, 2023
View reviewed changes
Copy link
Contributor

@mpirvu mpirvu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mpirvu
Copy link
Contributor

mpirvu commented Nov 7, 2023

jenkins test sanity plinuxjit,xlinuxjit,zlinuxjit,alinux64jit jdk17

@mpirvu
Copy link
Contributor

mpirvu commented Nov 8, 2023

jenkins test sanity plinux,xlinux,zlinux jdk17

@SajinaKandy
Copy link
Contributor Author

SajinaKandy commented Nov 8, 2023 •
edited
Loading

There are multiple failures due to different issues:

  1. Test_openjdk17_j9_sanity.functional_aarch64_linux_jit_Personal
    Hostname: cent8-aarch64-3
    Exception: java.nio.file.FileSystemException: /home/jenkins/workspace/Test_openjdk17_j9_sanity.functional_aarch64_linux_jit_Personal_testList_1: No space left on device

Issue: Raised infra issue #18418

  1. Test_openjdk17_j9_sanity.functional_ppc64le_linux_jit_Personal
    https://openj9-jenkins.osuosl.org/job/Test_openjdk17_j9_sanity.functional_ppc64le_linux_jit_Personal/119
    Hostname: openj9-cent8-1.novalocal
Testing: Create Criu Checkpoint Image without Restore
 [OUT] Performing CRIUSupport.checkpointJVM(), current thread name: main, Tue Nov 07 19:30:51 UTC 2023, System.currentTimeMillis(): 1699385451093, System.nanoTime(): 16860922390427242
 [OUT] CRIU needs to have the CAP_SYS_ADMIN or the CAP_CHECKPOINT_RESTORE capability: 
 [OUT] setcap cap_checkpoint_restore+eip criu

Issue: #18144

Testing: Create CRIU checkpoint image and restore three times - testMillisDelayBeforeCheckpointDone
***[TEST INFO 2023/11/07 19:36:40] ProcessKiller detected a timeout after 300000 milliseconds!***
INFO: Cannot find '/usr/bin/gdb' using 'gdb' from the path.
***[TEST INFO 2023/11/07 19:36:40] executing gdb -batch -x /tmp/debugger10913030175876115504.txt bash 3594168***
java.io.IOException: Cannot run program "gdb": error=2, No such file or directory
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073)

Issue: #17844 (comment)

  1. Test_openjdk17_j9_sanity.functional_s390x_linux_jit_Personal
    https://openj9-artifactory.osuosl.org/artifactory/ci-openj9/Test/Test_openjdk17_j9_sanity.functional_s390x_linux_jit_Personal/101/Test_openjdk17_j9_sanity.functional_s390x_linux_jit_Personal_testList_0.tap
    Hostname: rh8s390x02
Testing: Restore trace options test with -Xtrace before checkpoint - 2
         [OUT] Pre-checkpoint
         [OUT] Performing CRIUSupport.checkpointJVM(), current thread name: main, Tue Nov 07 13:00:36 EST 2023, System.currentTimeMillis(): 1699380036517, System.nanoTime(): 1699380036512962699
         [OUT] JVMDUMP034I User requested Java dump using '/home/jenkins/workspace/Test_openjdk17_j9_sanity.functional_s390x_linux_jit_Personal_testList_0/aqa-tests/TKG/output_16993780076867/cmdLineTester_criu_nonPortableRestore_Xdump_events_2/javacore.20231107.130036.235318.0002.txt' through CRIUSingleThreadModeJVMCRIUException
         [OUT] JVMDUMP010I Java dump written to /home/jenkins/workspace/Test_openjdk17_j9_sanity.functional_s390x_linux_jit_Personal_testList_0/aqa-tests/TKG/output_16993780076867/cmdLineTester_criu_nonPortableRestore_Xdump_events_2/javacore.20231107.130036.235318.0002.txt
         [OUT] java.lang.reflect.InvocationTargetException
         [OUT] JVMJITM044W Some or all compiled code in the code cache invalidated post restore.
         [OUT] JVMDUMP034I User requested Java dump using '/home/jenkins/workspace/Test_openjdk17_j9_sanity.functional_s390x_linux_jit_Personal_testList_0/aqa-tests/TKG/output_16993780076867/cmdLineTester_criu_nonPortableRestore_Xdump_events_2/javacore.20231107.130038.235318.0003.txt' through CRIUSingleThreadModeJVMCRIUException

         [OUT] Caused by: org.eclipse.openj9.criu.JVMRestoreException: Blocking operation is not allowed in CRIU single thread mode.
         [OUT] 	at java.base/jdk.internal.ref.PhantomCleanable.insert(PhantomCleanable.java:87)
         [OUT] 	at java.base/jdk.internal.ref.PhantomCleanable.<init>(PhantomCleanable.java:68)
         [OUT] 	at java.base/jdk.internal.ref.CleanerImpl$PhantomCleanableRef.<init>(CleanerImpl.java:164)
         [OUT] 	at java.base/java.lang.ref.Cleaner.register(Cleaner.java:220)
         [OUT] 	at java.base/java.lang.invoke.MethodHandleNatives$CallSiteContext.make(MethodHandleNatives.java:90)

Issue: #18399

  1. Test_openjdk17_j9_sanity.functional_x86-64_linux_Personal
    Hostname: ub20-x86-1
    Link: https://openj9-jenkins.osuosl.org/job/Test_openjdk17_j9_sanity.functional_x86-64_linux_Personal/455
Testing: Create and Restore Criu Checkpoint Image once - TestConcurrentModePostRestoreHookRunOnce
 [ [OUT] TestConcurrentModePostRestoreHookRunOnce() Pre-checkpoint, current thread name: main, Wed Nov 08 02:51:21 EST 2023, System.currentTimeMillis(): 1699429881464, System.nanoTime(): 16219968767466386
 [OUT] Performing CRIUSupport.checkpointJVM(), current thread name: main, Wed Nov 08 02:51:21 EST 2023, System.currentTimeMillis(): 1699429881469, System.nanoTime(): 16219968772444492
 [OUT] JVMDUMP034I User requested Java dump using '/home/jenkins/workspace/Test_openjdk17_j9_sanity.functional_x86-64_linux_Personal_testList_1/aqa-tests/TKG/output_16994242393885/cmdLineTester_criu_nonPortableRestore_3/javacore.20231108.025121.2472883.0001.txt' through CRIUSingleThreadModeJVMCRIUException

[OUT] JVMJITM044W Some or all compiled code in the code cache invalidated post restore.
 [OUT] JVMDUMP034I User requested Java dump using '/home/jenkins/workspace/Test_openjdk17_j9_sanity.functional_x86-64_linux_Personal_testList_1/aqa-tests/TKG/output_16994242393885/cmdLineTester_criu_nonPortableRestore_3/javacore.20231108.025124.2472883.0002.txt' through CRIUSingleThreadModeJVMCRIUException
 [OUT] JVMDUMP010I Java dump written to /home/jenkins/workspace/Test_openjdk17_j9_sanity.functional_x86-64_linux_Personal_testList_1/aqa-tests/TKG/output_16994242393885/cmdLineTester_criu_nonPortableRestore_3/javacore.20231108.025124.2472883.0002.txt
 [OUT] Exception in thread "main" java.lang.BootstrapMethodError: bootstrap method initialization exception

 [OUT] Caused by: org.eclipse.openj9.criu.JVMRestoreException: Blocking operation is not allowed in CRIU single thread mode.
 [OUT] 	at java.base/jdk.internal.ref.PhantomCleanable.insert(PhantomCleanable.java:87)
 [OUT] 	at java.base/jdk.internal.ref.PhantomCleanable.<init>(PhantomCleanable.java:68)
 [OUT] 	at java.base/jdk.internal.ref.CleanerImpl$PhantomCleanableRef.<init>(CleanerImpl.java:164)

Issue: #18399

  1. Test_openjdk17_j9_sanity.functional_x86-64_linux_jit_Personal
    Hostname: cent7-x64-5
    Link: https://openj9-jenkins.osuosl.org/job/Test_openjdk17_j9_sanity.functional_x86-64_linux_jit_Personal/132/
Testing: Create CRIU checkpoint image and restore once - testMXBeanUpTime
[OUT] 00:29:55.332 0x17000          j9criu.15       - After checkpoint criu_dump(), j9time_nano_time() returns 16193582648587782, j9time_current_time_nanos() returns 1699403395332726332
 [OUT] 00:29:55.333 0x17000          j9criu.14       - After restore, restoreNanoUTCTime = 1699403395332726332, checkpointNanoUTCTime = 1699403393016732896, checkpointRestoreTimeDelta = 2315993436, restoreNanoTimeMonotonic = 16193582648587782, checkpointNanoTimeMonotonic = 16193580332594795, nanoTimeMonotonicClockDelta = 2315992987
 [OUT] JVMJITM044W Some or all compiled code in the code cache invalidated post restore.
 [OUT] 00:29:55.411 0x17000          j9criu.10       < Java_org_eclipse_openj9_criu_CRIUSupport_checkpointJVMImpl
 [OUT] 00:29:55.413 0x17000           j9jcl.533      - RuntimeMXBeanImpl_getUptimeImpl timeNow (1699403395413) vmStartTime (1699403379280) criuTimeDeltaMillis (2315)
 [OUT] FAILED: testMXBeanUpTime() - uptimeAfterCheckpoint 13818 can't be greater than uptimeBeforeCheckpoint 12207 + 1500
 [OUT] Removed test output files
 [OUT] finished script

Issue: #18384

@mpirvu
Copy link
Contributor

mpirvu commented Nov 8, 2023 •
edited
Loading

@SajinaKandy Is there anything that could have been caused by this PR? I don't see any connection so far.
In fact, since we only modify a few of the tests, only those tests could show a problem, if any.

@SajinaKandy
Copy link
Contributor Author

@mpirvu The existing test failures I posted above are unrelated to the changes here.
I am waiting for the Test_openjdk17_j9_sanity.functional_ppc64le_linux_Personal to complete after which we can confirm the same for all tests.

@SajinaKandy
Copy link
Contributor Author

@mpirvu The last ppc64le also fails with [OUT] CRIU needs to have the CAP_SYS_ADMIN or the CAP_CHECKPOINT_RESTORE capability:

https://openj9-jenkins.osuosl.org/job/Test_openjdk17_j9_sanity.functional_ppc64le_linux_Personal_testList_0/348/console

So we can conclude none of these failures are happening due to the changes introduced in the SSL tests here.

@mpirvu
Copy link
Contributor

mpirvu commented Nov 8, 2023

Merging the PR based on the comments above

@mpirvu mpirvu merged commit 2dc399e into eclipse-openj9:master Nov 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@mpirvu mpirvu mpirvu approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@SajinaKandy @mpirvu