[
https://issues.apache.org/jira/browse/HBASE-26492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17464211#comment-17464211
]
Andrew Kyle Purtell commented on HBASE-26492:
---------------------------------------------
Right, it is also possible classes compiled by a third party with the incorrect
environment were copied in. I remember either option was possible, although I
also remember your java version was 11 in your container so that would not have
been the exact container we use, right? I did try to use the Docker option. At
the the the Dockerfile had bit rotted so the container build failed for me.
Never looked at it again.
Anyway, I could be convinced to set up a build server or container or whatever
so Nick/Sean if your solution to a problem is some magic in the Docker image, I
would ask that this be documented so it can be replicated rather than have us
rely on build magic in a black box container.
> [branch-2, hbase-thirdparty, Java 8] TestUnloadAccessController and other
> unit tests fail to start due to ByteBuffer link error
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-26492
> URL: https://issues.apache.org/jira/browse/HBASE-26492
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 2.4.8, 2.4.9
> Environment: Java 1.8.0_312, vendor: Azul Systems, Inc., runtime:
> /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre
> OS name: "mac os x", version: "12.0.1", arch: "aarch64", family: "mac"
> Reporter: Andrew Kyle Purtell
> Priority: Major
> Fix For: 2.5.0, 2.6.0, 2.4.10
>
>
> org.apache.hadoop.hbase.security.access.TestUnloadAccessController
> Hang in setUpBeforeClass. Master will not initialize. Root cause is a
> NoSuchMethodError.
> {noformat}
> 2021-11-26 19:09:56,465 WARN
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=0,port=62950]
> ipc.RpcExecutor$Handler(370):
> Handler errors java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.hbase.thirdparty.com.google.protobuf.CodedOutputStream$HeapNioEncoder.flush(CodedOutputStream.java:1546)
> at
> org.apache.hadoop.hbase.ipc.ServerCall.writeToCOS(ServerCall.java:378)
> at
> org.apache.hadoop.hbase.ipc.ServerCall.createHeaderAndMessageBytes(ServerCall.java:385)
> at
> org.apache.hadoop.hbase.ipc.ServerCall.createHeaderAndMessageBytes(ServerCall.java:363)
> at
> org.apache.hadoop.hbase.ipc.ServerCall.setResponse(ServerCall.java:267)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:168)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:354)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:334)
> {noformat}
> This is a known issue with ByteBuffer in JDK 8 vs ByteBuffer in later
> versions. When code is compiled with Java 9 or later using a specific subset
> of ByteBuffer APIs, the resulting bytecode will not link with Java 8's
> runtime. It works fine the other way. When compiled with Java 8, the bytecode
> will link with later Java runtimes just fine.
> protobuf included into hbase-thirdparty was likely compiled with Java 9 or
> later. We shade that bytecode as is into hbase-thirdparty. Tests were
> attempted with Java 8, so this failure case manifested.
> Apache Maven 3.8.3 (ff8e977a158738155dc465c6a97ffaf31982d739)
> Java version: 1.8.0_312, vendor: Azul Systems, Inc., runtime:
> /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre
> OS name: "mac os x", version: "12.0.1", arch: "aarch64", family: "mac"
> We should be able to fix this problem by compiling protobuf with Java 8 and
> then shading the result when building hbase-thirdparty.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
