lhotari commented on code in PR #22054:
URL: https://github.com/apache/pulsar/pull/22054#discussion_r1492087822
##########
docker/pulsar/scripts/install-glibc-compat.sh:
##########
@@ -18,13 +18,18 @@
# under the License.
#
-set -x
+set -e -x
-# TODO: remove these lines once grpcio doesn't need to compile from source on
ARM64 platform
-ARCH=$(uname -m | sed -r 's/aarch64/arm64/g' | awk '!/arm64/{$0="amd64"}1')
-if [ "${ARCH}" == "arm64" ]; then
- apt update
- apt -y install build-essential python3-dev
+ARCH=$(uname -m)
+if [ "$ARCH" == "x86_64" ]
+then
+ cd /tmp
+ echo 'https://storage.sev.monster/alpine/edge/testing' | tee -a
/etc/apk/repositories
+ wget
https://storage.sev.monster/alpine/edge/testing/x86_64/sevmonster-keys-1-r0.apk
+ apk add --no-cache --allow-untrusted ./sevmonster-keys-1-r0.apk
+ apk update
+ apk add gcompat libuuid
+ rm /lib/ld-linux-x86-64.so.2
+ apk add --no-cache --force-overwrite glibc glibc-bin
+ rm *.apk
Review Comment:
> I would still prefer to use Corretto JVM linked with musl. Mainly so that:
>
> 1. we can always control the base OS version, without depending on this
OpenJDK provider to have a release
I'd assume that Liberica has more resources for testing the base image's
compatibility making it a "certified" option. Isn't that relevant for us?
Why would we need to control the base OS version? If we really need to do
that, that could be done by building the base image in a similar way as
Liberica is doing it.
I'm assuming that we have a use case where we need to use glibc because of
different reasons such as the Kinesis producer example.
[glibc's malloc has it's warts in running
Java](https://bugs.openjdk.org/browse/JDK-8193521) and even Bellsoft provides
alternative malloc implementations in their Alpaquita Linux base images
(https://docs.bell-sw.com/alpaquita-linux/latest/how-to/malloc/). Bellsoft's
Alpaquita is similar to Alpine, but not compatible. It is optimized for running
Java in containers (https://bell-sw.com/alpaquita-linux/).
[Bellsoft has some perf
graphs](https://bell-sw.com/assets/files/WP_Alpaquita_Linux.pdf#page=8) showing
that standard musl is slower in certain microbenchmarks compared to glibc and
their's "musl perf" which is an optimized version of musl. I'm not sure how
valid that would be to Pulsar / Bookkeeper use cases. Perhaps there isn't a
significant difference at all.
Staying on glibc seems like a safe bet. I don't see what benefits switching
to musl would bring. The part that is not optimal for Java in glibc is the
malloc implementation (and there are multiple options to replace that, jemalloc
as one of the most popular ones). In the bellsoft/liberica-openjdk-alpine:21
base image, glibc takes about 7MB of uncompressed space in the image so the
additional size of glibc isn't a problem for our use cases.
What does musl give us that we don't have with glibc?
> 2. the track record of Corretto in the last years
What makes Corretto significantly better than Liberica OpenJDK? Is there
something outstanding in Corretto that isn't in Liberica OpenJDK (or Eclipse
Temurin)?
> In the end, I would prefer to just build the Glibc as a pre-step, so we'd
be having both x86_64 and arm binaries and no dependencies.
What do you mean as a pre-step? Isn't it going to be a problem if a single
process would be using both glibc and musl? Let's say that a dynamically linked
JNI library would require glibc for some reason and the Java process would be
using musl. Does that really work and make sense?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
