我在sr的hadoop_env.sh脚本看到有HADOOP_CLASSPATH
我自己没有配置任何有关hadoop环境变量
大概率是找不到类。你把hadoop_env.sh脚本里的HADOOP_CLASSPATH注释掉,自己加CLASSPATH环境变量把:lib/hadoop/common、lib/hadoop/common/lib、lib/hadoop/hdfs、lib/hadoop/hdfs/lib下的所有jar包以及及$JAVA_HOME/lib/dt.jar 、$JAVA_HOME/lib/tools.jar都加上试试。
加了一波 还是一样的错呢 有点奇怪
换成JDK8试试
试了一波 JDK8 错误更多
JNIEnv* getJNIEnv(void)
{
…
jthrowable jthr = NULL;
jthr = initCachedClasses(state->env);
if (jthr) {
printExceptionAndFree(state->env, jthr, PRINT_EXC_ALL,
"initCachedClasses failed");
goto fail;
}
return state->env;
................
}
jthrowable initCachedClasses(JNIEnv* env) {
mutexLock(&jclassInitMutex);
if (!jclassesInitialized) {
// Set all the class names
cachedJavaClasses[JC_CONFIGURATION].className =
“org/apache/hadoop/conf/Configuration”;
…
…
cachedJavaClasses[JC_CFUTURE].className =
"java/util/concurrent/CompletableFuture";
// Create and set the jclass objects based on the class names set above
jthrowable jthr;
int numCachedClasses =
sizeof(cachedJavaClasses) / sizeof(javaClassAndName);
for (int i = 0; i < numCachedClasses; i++) {
jthr = initCachedClass(env, cachedJavaClasses[i].className,
&cachedJavaClasses[i].javaClass);
if (jthr) {
mutexUnlock(&jclassInitMutex);
return jthr;
}
}
jclassesInitialized = 1;
}
mutexUnlock(&jclassInitMutex);
return NULL;
}
上面是libhdfs与问题相关的代码片段,结合给出的cn退出时的调用栈可以判断是在initCachedClasses方法里cache java类时出错了。
由于是由staros发起的对libhdfs里方法的调用,而staros是闭源的所以没有staros源代码无法做任何事来进一步分析了。如果staros是开源可以在initCachedClasses方法里在出错前添加一些跟踪信息重新编译连接来分析问题。所以强烈建议starrocks对staros的依赖做成可插拔的插件形式,让用户选择是用闭源还是开源的插件实现。
你现在只能找有staros源代码的人帮你进一步分析问题了。或者不要用hdfs了,用MinIO做存贮吧。
这个应该不是root cause,它这里正常加载不出来也不会crash,crash是因为加载不到JAVA method,大概率还是JDK相关的问题
根因是在initCachedClasses方法里cache java类出错了。然后它想去打印调用栈信息,通过libjvm从线程信息中获取调用栈信息,可能是在JNI调用中不允许这样是获取线程信息导致强制终止进程,这些都是前面的出错引发出来的问题不是根因,根因是我上面所说的。
在initCachedClasses方法里cache java类出错后引起强制终止进程可能与这个libjvm bug 有关(https://issues.apache.org/jira/browse/HDFS-16084)。
我现在启动CN的时候不在创建storage volume,直接建立iceberg catalog,然后查询外表发现3分钟左右,cn就挂了,报另外一个错误[warn] Error from accept() call: Invalid argument