记一次sapjco 运行时错误排查

Caused by: java.lang.ExceptionInInitializerError: JCO.classInitialize(): Could not load middleware layer 'com.sap.mw.jco.rfc.MiddlewareRFC'JCO.nativeInit(): Could not initialize dynamic link library sapjcorfc [/home/yyapp/tomcat/apache-tomcat-6.0.41/lib/libsapjcorfc.so: /home/yyapp/tomcat/apache-tomcat-6.0.41/lib/libsapjcorfc.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch)]. java.library.path [/usr/java/jdk1.6.0_21/jre/lib/i386/server:/usr/java/jdk1.6.0_21/jre/lib/i386:/usr/java/jdk1.6.0_21/jre/../lib/i386:/home/yyapp/tomcat/apache-tomcat-6.0.41/lib:/usr/java/packages/lib/i386:/lib:/usr/lib]

定位问题

先从报错的关键信息入手（这程序的异常报错写的真好，值得我们学习）

caused by：Could not initialize dynamic link library sapjcorfc wrong ELF class: **ELFCLASS64 (Possible cause: architecture word width mismatch)]. java.library.path**[/usr/java/jdk1.6.0_21/jre/lib/i386/server:/usr/java/jdk1.6.0_21/jre/lib/i386:/usr/java/jdk1.6.0_21/jre/../lib/i386:/home/yyapp/tomcat/apache-tomcat-6.0.41/lib:/usr/java/packages/lib/i386:/lib:/usr/lib]

大致的意思是：
不能加载动态链接库 sapjcorfc, 错误的 ELF class: ELFCLASS64(可能的原因：架构字宽不匹配)
google 了下，基本问题原因定位到 java 版本的问题，需要64位的 java，但是用的是32位的 java。
从表报错中的/usr/java/jdk1.6.0_21/jre/lib/i386/ 确认确实是使用了32位的java。

确认问题

于是输入 java -version 发现版本是 jdk1.6.0_45 64bit 的。（看来这问题没那么简单）

[root@vm-yysale-app01 yyapp]# java -versionjava version "1.6.0_45"Java(TM) SE Runtime Environment (build 1.6.0_45-b06)Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)

查看 tomcat 启动时的 java.library.path, 也是64位的 jdk，完全正常。

/home/yyapp/java/jdk1.6.0_45/jre/lib/amd64/server:/home/yyapp/java/jdk1.6.0_45/jre/lib/amd64:/home/yyapp/java/jdk1.6.0_45/jre/../lib/amd64:/home/yyapp/tomcat/apache-tomcat-6.0.41/lib:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

再回想到这个错误是运行时调用SAP RFC 才会触发，猜测可能是调用 SAP RFC 时它压根不用之前 tomcat 给他准备好的java 路径，可能是在 so 文件里采用自己的方式获取运行的 java，就拿到了32位的 jdk，导致出错。

用whereis java 查看默认的 java 路径

[root@vm-yysale-app01 java]# whereis javajava: /usr/bin/java /usr/share/java

[root@vm-yysale-app01 java]# ll /usr/bin/javalrwxrwxrwx. 1 root root 26 12月 15 2014 /usr/bin/java -> /usr/java/default/bin/java

[root@vm-yysale-app01 java]# ll /usr/java/总用量 4lrwxrwxrwx. 1 root root   28 4月  12 15:38 default -> /usr/java/jdk1.6.0_21drwxr-xr-x. 2 root root 4096 4月  12 15:37 jdk1.6.0_21lrwxrwxrwx. 1 root root   28 4月  12 15:38 latest -> /usr/java/jdk1.6.0_21

终于找到你，幸好我没放弃！原来就藏到这里了。系统默认版本是32位 jdk。

解决方案

把软链修改成64位 java 的地址，重新启动 tomcat触发 SAPRFC 接口测试，问题解决: )

[root@vm-yysale-app01 java]# ll /usr/java/总用量 4lrwxrwxrwx. 1 root root   28 4月  12 15:38 default -> /home/yyapp/java/jdk1.6.0_45drwxr-xr-x. 2 root root 4096 4月  12 15:37 jdk1.6.0_21lrwxrwxrwx. 1 root root   28 4月  12 15:38 latest -> /home/yyapp/java/jdk1.6.0_45

小记

• 把 tomcat 启动过程执行的步骤搞清楚对排查问题帮助非常大。
  可以先从startup.sh 和 catalina.sh两个脚本入手。
• 报错信息准确对问题排查是多么的重要，所以写代码的时候也多写有用的报错日志
• 运维的标准化是如此重要，这个问题主要还是这台测试机器 jdk 装了两个版本，且配置有问题，导致留了这个坑，估计老机器还存在不少类似问题。
  

在这里强烈支持咱们的运维部同事们的运维标准版，和小戚在做的老系统迁移到新运维标准化机器（填坑运动），尤其是熊大和熊二在这方面的努力。1024个赞!!!
公司的博客：(http://it.nfsq.com.cn/index.php/2016/04/13/sapjco_runtime_erorr_handle/)