From 55c4c7b64f69ac73ee5f001a8fa1bd2a3163b90e Mon Sep 17 00:00:00 2001 From: Nick Hill Date: Fri, 17 Nov 2023 15:15:45 -0800 Subject: [PATCH] fix: Remove explicit arg that enables litelinks' use of openssl This won't change current behaviour since the default is to use netty's openssl-based TLS implementation anyhow. But it will allow overriding to use the native jdk TLS impl when needed. Signed-off-by: Nick Hill --- src/main/scripts/start.sh | 4 ---- 1 file changed, 4 deletions(-) diff --git a/src/main/scripts/start.sh b/src/main/scripts/start.sh index c5fe44eb..dbd5b3e0 100644 --- a/src/main/scripts/start.sh +++ b/src/main/scripts/start.sh @@ -367,9 +367,6 @@ echo "SHUTDOWN_TIMEOUT_MS=$SHUTDOWN_TIMEOUT_MS" LITELINKS_ARGS="-Dlitelinks.cancel_on_client_close=true -Dlitelinks.threadcontexts=log_mdc -Dlitelinks.shutdown_timeout_ms=${SHUTDOWN_TIMEOUT_MS} -Dlitelinks.produce_pooled_bytebufs=true" -# have litelinks use OpenSSL instead of JDK TLS implementation (faster) -LL_OPENSSL_ARG="-Dlitelinks.ssl.use_jdk=false" - # These two args are needed to use netty's off-the-books direct buffer allocation NETTY_DIRECTBUF_ARGS="-Dio.netty.tryReflectionSetAccessible=true --add-opens=java.base/java.nio=ALL-UNNAMED" # this defaults to equal max heap, which can result in container OOMKilled @@ -414,7 +411,6 @@ exec $JAVA_HOME/bin/java -cp "$LL_JAR:lib/*" -XX:+UnlockExperimentalVMOptions -X ${JAVA_MAXDIRECT_ARG} ${NETTY_MAXDIRECT_ARG} ${NETTY_DISABLE_CHECK_ARGS} \ ${GRPC_USE_SHARED_ALLOC_ARG} \ ${SSL_PK_ARG} ${TRUSTSTORE_ARG} ${LITELINKS_ARGS} ${CUSTOM_JVM_ARGS} \ - $LL_OPENSSL_ARG \ $PRIVATE_ENDPOINT_ARG \ $LOG_CONFIG_ARG $LOG_PERF_ARGS \ com.ibm.watson.litelinks.server.LitelinksService \