youngkermit8-coder opened a new issue, #7132:
URL: https://github.com/apache/rocketmq-dashboard/issues/7132
### Before Creating the Bug Report
- [x] I searched the repository's issues and PRs for Okio, OkHttp, OTLP and
the missing-method error; I did not find an equivalent open or merged
compatibility fix in these bounded searches.
- [x] This is a Studio packaged-runtime issue, not a live Tencent service
error or another RocketMQ repository's usage question.
- [x] The exact source version and controlled reproduction are stated below.
### Studio Version
`rocketmq-studio` at `127c47b06a268cc74224d5f34c56ec7c36ac0d55`, built from
unchanged source. No product patch, SDK upgrade, test dependency overlay or
runtime HTTP dependency override was applied for the baseline reproduction.
### Runtime Environment
Windows / Temurin Java 21.0.12+8 / Maven 3.9.9. A standalone diagnostic
calls the real Tencent Trocket SDK against an ephemeral loopback HTTP endpoint
with dummy credentials. It runs through the normally packaged application's
Spring Boot `PropertiesLauncher`, without starting the Studio application
context. No MySQL, real cloud account, broker, NameServer or customer data is
needed.
### Connected RocketMQ Cluster
None. This reproduces the control-plane SDK's HTTP transport locally, before
any request reaches the synthetic endpoint. Tencent SDK version: 3.1.1498;
RocketMQ dependency version: 5.5.0.
### Build Toolchain
Java 21; Maven 3.9.9; Python 3.11.15 for the existing material gate. `mvn -o
-B -ntp -DskipTests package` completed normally, including the existing
material gate (278 components). Its three existing material warnings for
logback-classic, logback-core and reflections remain; this is not a
warning-free build. This package command deliberately skips test execution and
is not a full-regression or official CI pass.
The first local attempt stopped at that gate because Windows resolved
`python3` to the Microsoft Store placeholder. I preserved that failure and
reran in a separate directory with a process-local executable alias to the
installed Python. No product POM, source, dependency or gate was altered to
repair the toolchain.
### Describe the Bug
The unchanged application archive loads `okhttp-jvm-5.3.2.jar` together with
`okio-jvm-3.4.0.jar` and `kotlin-stdlib-1.9.25.jar`. A real
`TrocketClient.DescribeMessageList` call fails with:
```text
java.lang.NoSuchMethodError: 'okio.Socket okio.Okio.socket(java.net.Socket)'
at okhttp3.internal.connection.BufferedSocketKt.asBufferedSocket
at okhttp3.internal.connection.ConnectPlan.connectSocket
LOOPBACK_REQUESTS_RECEIVED 0
```
Normal packaging therefore succeeds while this packaged SDK transport cannot
perform even a local success request. I am not claiming every Studio/RocketMQ
operation fails, that the SDK contacted Tencent, or that a deployed customer
incident was observed.
### Steps to Reproduce
Build the pinned version's `server/` normally. Save the following external
fixture as `PackagedTencentSdkProbe.java`. It must remain outside the project's
source tree and must not replace packaged dependencies. All credentials and
resource identifiers below are synthetic.
```java
import com.sun.net.httpserver.HttpServer;
import com.tencentcloudapi.common.Credential;
import com.tencentcloudapi.common.profile.ClientProfile;
import com.tencentcloudapi.common.profile.HttpProfile;
import com.tencentcloudapi.trocket.v20230308.TrocketClient;
import
com.tencentcloudapi.trocket.v20230308.models.DescribeMessageListRequest;
import java.net.InetSocketAddress;
import java.nio.charset.StandardCharsets;
import java.util.concurrent.atomic.AtomicInteger;
public class PackagedTencentSdkProbe {
public static void main(String[] args) throws Exception {
for (String name : new String[] {"okhttp3.OkHttpClient",
"okio.Okio", "kotlin.KotlinVersion",
"com.tencentcloudapi.trocket.v20230308.TrocketClient"}) {
Class<?> type = Class.forName(name);
System.out.println("CLASS_ORIGIN " + name + " "
+
type.getProtectionDomain().getCodeSource().getLocation());
}
AtomicInteger received = new AtomicInteger();
HttpServer server = HttpServer.create(new
InetSocketAddress("127.0.0.1", 0), 0);
server.createContext("/", exchange -> {
try (exchange) {
exchange.getRequestBody().readAllBytes();
received.incrementAndGet();
byte[] response =
("{\"Response\":{\"RequestId\":\"loopback\",\"TaskRequestId\":\"task\","
+
"\"TotalCount\":0,\"Data\":[]}}").getBytes(StandardCharsets.UTF_8);
exchange.getResponseHeaders().set("Content-Type",
"application/json");
exchange.sendResponseHeaders(200, response.length);
exchange.getResponseBody().write(response);
}
});
server.start();
int exitCode = 0;
try {
HttpProfile http = new HttpProfile();
http.setProtocol(HttpProfile.REQ_HTTP);
http.setEndpoint("127.0.0.1:" + server.getAddress().getPort());
http.setConnTimeout(5);
http.setReadTimeout(5);
ClientProfile profile = new ClientProfile();
profile.setHttpProfile(http);
TrocketClient client = new TrocketClient(new
Credential("local-test-id", "local-test-secret"),
"ap-shanghai", profile);
DescribeMessageListRequest request = new
DescribeMessageListRequest();
request.setInstanceId("rmq-loopback");
request.setTopic("orders");
request.setStartTime(1_600_000_000_000L);
request.setEndTime(1_600_001_000_000L);
request.setOffset(0L);
request.setLimit(100L);
request.setTaskRequestId("task");
client.DescribeMessageList(request);
System.out.println("SDK_CALL_SUCCEEDED");
} catch (Throwable failure) {
System.out.println("SDK_CALL_FAILED " +
failure.getClass().getName() + ": " + failure.getMessage());
failure.printStackTrace(System.out);
exitCode = 2;
} finally {
server.stop(0);
}
System.out.println("LOOPBACK_REQUESTS_RECEIVED " + received.get());
if (exitCode == 0 && received.get() != 1) {
exitCode = 3;
}
System.exit(exitCode);
}
}
```
Compile against the archive's extracted libraries, but run with the Boot
archive itself. A POSIX-shell recipe is shown below; my current run used the
equivalent Windows JDK commands. The recipe is not an additional independently
executed test.
```sh
# From server/, with the external .java fixture in this directory:
mvn -B -ntp -DskipTests package
jar_path="$(pwd)/target/rocketmq-studio-3.0.0.jar"
mkdir -p compile-libs probe-classes
(cd compile-libs && jar xf "$jar_path" BOOT-INF/lib)
javac -encoding UTF-8 -cp 'compile-libs/BOOT-INF/lib/*' \
-d probe-classes PackagedTencentSdkProbe.java
java -Xmx256m -Dloader.main=PackagedTencentSdkProbe \
-Dloader.path=probe-classes -cp "$jar_path" \
org.springframework.boot.loader.launch.PropertiesLauncher
```
Only diagnostic classes are added at runtime; do not add the extracted
compile libraries to `loader.path` or select a newer Okio manually, because
that changes the runtime being diagnosed.
### What Did You Expect to See?
The SDK should reach the local endpoint, decode its supplied success
response and print `SDK_CALL_SUCCEEDED` / `LOOPBACK_REQUESTS_RECEIVED 1`.
Compatible dependencies should preserve SDK logging, error and timeout
behavior, rather than catching `LinkageError` or hiding the failed transport.
### What Did You See Instead?
The current pinned unchanged package prints nested-JAR origins for the
versions above, fails with the missing `okio.Okio.socket` method, receives zero
loopback requests and exits 2. The diagnostic does not modify the application
JAR. A separate local audit checked all 1,142 exported server files against the
pinned Git objects and on-disk source, the archive CRC/payload hashes and
actual nested class origins. This is source/artifact verification, not
additional behavioral tests.
The local application JAR's SHA-256 is
`e0ddef469f6f74e556176a3e60912102c05314b0e34f822f152977aa31ba9cfe` (for this
build, not a universal reproducible-build claim). The pinned [server
POM](https://github.com/apache/rocketmq-dashboard/blob/127c47b06a268cc74224d5f34c56ec7c36ac0d55/server/pom.xml)
is unchanged.
### Additional Context / Design Question
An earlier separately pinned investigation also reproduced this
dependency-family failure in an explicitly constructed, nonempty OTLP HTTP span
export. That is supporting historical evidence, not a fresh whole-trunk
telemetry test or proof that Studio enables the exporter by default.
Before submitting a dependency change, could maintainers confirm the
intended shared HTTP/Okio/Kotlin compatibility policy? The resolved runtime
also includes legacy Tencent OkHttp/Okio coordinates with overlapping packages,
so a one-off manual classpath override is not an acceptable delivery. A
coherent proposal should verify both SDK transport and the OTLP HTTP consumer,
logging/error/timeout paths, final packaged class origins, and the existing
material gate. SDK versions, pagination, request-budget logic and telemetry
defaults should remain separate.
A local prototype was prepared before opening this discussion; no code PR is
being submitted here and no maintainer agreement is inferred. Historical
prototype tests are not claimed as current-baseline validation. Existing
warnings and failed diagnostic attempts remain preserved locally. No
credentials, customer endpoints, raw authenticated logs, JARs or databases are
attached. AI assistance was used for investigation and verification.
### Are You Willing to Submit a Pull Request?
- [x] Yes, after the project's feedback and the applicable fresh validation
gates.
--
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]
