[
https://issues.apache.org/jira/browse/KAFKA-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17936504#comment-17936504
]
Christofer Dutz commented on KAFKA-19007:
-----------------------------------------
Some additional Links to the issue:
[https://bugs.openjdk.org/browse/JDK-8345296]
[https://github.com/corretto/corretto-21/issues/85]
[https://forums.docker.com/t/image-builds-fail-on-new-macbook-despite-working-fine-on-prior-apple-silicon/145772/5?u=bluepuma77]
> Issues running the apache/kafka docker container on M4 Macs with OS >= 15.2
> ---------------------------------------------------------------------------
>
> Key: KAFKA-19007
> URL: https://issues.apache.org/jira/browse/KAFKA-19007
> Project: Kafka
> Issue Type: Bug
> Components: docker
> Affects Versions: 3.9.0
> Reporter: Christofer Dutz
> Priority: Major
>
> It seems there's an odd issue running java inside docker containers running
> on MacOS systems with an M4 chip and using an OS version that's 15.2 or
> greater. In this case the JVM simply dies with a core-dump.
> This can be avoided, by passing "-XX:UseSVE=0" to the jvm, which can be done
> by setting KAFKA_OPTS="-XX:UserSVE=0". However, this doesn't completely seem
> to work.
> I was using TestContainers to start Kafka in docker, and inside the container
> the file: /opt/kafka/bin/kafka-run-class.sh contains this block of code:
> {code:java}
> if [ "x$GC_LOG_ENABLED" = "xtrue" ]; then
> GC_LOG_FILE_NAME=$DAEMON_NAME$GC_FILE_SUFFIX
> # The first segment of the version number, which is '1' for releases before
> Java 9
> # it then becomes '9', '10', ...
> # Some examples of the first line of `java --version`:
> # 8 -> java version "1.8.0_152"
> # 9.0.4 -> java version "9.0.4"
> # 10 -> java version "10" 2018-03-20
> # 10.0.1 -> java version "10.0.1" 2018-04-17
> # We need to match to the end of the line to prevent sed from printing the
> characters that do not match
> JAVA_MAJOR_VERSION=$("$JAVA" -version 2>&1 | sed -E -n 's/.* version
> "([0-9]*).*$/\1/p')
> if [[ "$JAVA_MAJOR_VERSION" -ge "9" ]] ; then
>
> KAFKA_GC_LOG_OPTS="-Xlog:gc*:file=$LOG_DIR/$GC_LOG_FILE_NAME:time,tags:filecount=10,filesize=100M"
> else
> KAFKA_GC_LOG_OPTS="-Xloggc:$LOG_DIR/$GC_LOG_FILE_NAME -verbose:gc
> -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps
> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M"
> fi
> fi {code}
> On these systems, the execution of:
> {code:java}
> JAVA_MAJOR_VERSION=$("$JAVA" -version 2>&1 | sed -E -n 's/.* version
> "([0-9]*).*$/\1/p') {code}
> Results in the JAVA_MAJOR_VERSION being set to the value "Aborted", which
> makes the if statement go into the else branch. This then sets
> PrintGCDateStamps, which makes the JVM die with an error message.
> Currently I have noticed that on these systems using the apache/kafka-native
> image seems to work around the issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
