yb-client jar compiled against jdk 11 does not work with jdk 8 #6712
Comments
|
To prevent this, build with |
|
@gunnarmorling : Your blog post is the clearest description of the underlying signature mismatch I've seen on this topic so far, thanks for writing it and pointing us to it. |
iSignal
added a commit
that referenced
this issue
Mar 10, 2021
Summary: See #6712 for more details. The signature of ByteBuffer::flip changed between JDK 8 and 9. So when the client is compiled using Java >8 and run with Java 8, it fails to "link" the flip method and results in a NoSuchMethod error. The fix converts the code to always use Buffer.flip instead of the derived method. This should be not result in a loss of functionality because the implementation of the flip in the derived class seems to be the same as the parent class but just returns a different type. See http://hg.openjdk.java.net/jdk9/sandbox/jdk/file/7d9bd66d2bb9/src/java.base/share/classes/java/nio/X-Buffer.java.template#l1148 The issue highlights another problem in the Java RPC client - it seems like the error NoSuchMethodException is just swallowed somewhere along the path. The 'sync' YBClient calls the AsyncYBClient but it might not provide an 'errback' for the error that results from this call. Test Plan: Compile with Java 11, run with Java 8, verify the error is fixed. Reviewers: arnav, streddy, daniel Reviewed By: streddy, daniel Subscribers: streddy, yugaware Differential Revision: https://phabricator.dev.yugabyte.com/D10183
YintongMa
pushed a commit
to YintongMa/yugabyte-db
that referenced
this issue
May 26, 2021
Summary: See yugabyte#6712 for more details. The signature of ByteBuffer::flip changed between JDK 8 and 9. So when the client is compiled using Java >8 and run with Java 8, it fails to "link" the flip method and results in a NoSuchMethod error. The fix converts the code to always use Buffer.flip instead of the derived method. This should be not result in a loss of functionality because the implementation of the flip in the derived class seems to be the same as the parent class but just returns a different type. See http://hg.openjdk.java.net/jdk9/sandbox/jdk/file/7d9bd66d2bb9/src/java.base/share/classes/java/nio/X-Buffer.java.template#l1148 The issue highlights another problem in the Java RPC client - it seems like the error NoSuchMethodException is just swallowed somewhere along the path. The 'sync' YBClient calls the AsyncYBClient but it might not provide an 'errback' for the error that results from this call. Test Plan: Compile with Java 11, run with Java 8, verify the error is fixed. Reviewers: arnav, streddy, daniel Reviewed By: streddy, daniel Subscribers: streddy, yugaware Differential Revision: https://phabricator.dev.yugabyte.com/D10183
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Repro steps:
java -versionshows > Java 8 (Java 9 at least) and run./yb_build.sh --java-only<path to java8> -jar java/yb-cli/target/yb-cli-0.8.0-SNAPSHOT.jar. At the prompt, type the commandsconnect --masters 127.0.0.1:7100andlist mastersFailed to fetch masters info for database at 127.0.0.1:7100, error: com.stumbleupon.async.TimeoutException: Timed out after 10000ms when joining Deferred@503928724(state=RUNNING, result=tablet_locations { tablet_id: "YB Master" replicas { ts_info { permanent_uuid: "e4443d784f6847c08a792e6f2535f667" private_rpc_addresses { host: "127.0.0.1" port: 7100 } } role: LEADER } stale: false partition { partition_key_start: "" partition_key_end: "" } } , callback=release master lookup permit -> retry RPC -> wakeup thread Spring Shell, errback=release master lookup permit -> retry RPC after error -> wakeup thread Spring Shell)The same error also repros through YW create universe.
When running with DEBUG logging the full details of the error are seen (ips are different):
The reason for this error is that the flip method of CharBuffer has a different signature in Java 8 and Java 11 (returns ByteBuffer vs Buffer). This causes a "runtime link" error (a more accurate description is at apache/felix#114).
@Arnav15
The text was updated successfully, but these errors were encountered: