jvm securerandom.source 导致的sqoop问题分析
2017-06-08 21:23
183 查看
在利用sqoop做抽取数据的同步过程中,经常发生以下错误。我们一直以为是oracle数据库没有打开或者某种连接异常,导致经常要重跑多次才能成功,甚至一度靠加入调度系统的智能重跑关键字中让任务多次重试,一直未定位到根本问题并找到解决办法(如下图),会影响调度成功率。
而这次,我们临时要在新环境跑sqoop任务,只起了一个sqoop客户端,失败的概率特别高,所以找到这个问题的解决办法就显得异常急迫。我回顾一下当时的解决思路:
找dba沟通,明确问题确实不是出在oracle数据库那边,因为数据库的报错一定会返回ORA等异常,而这里明显没到数据库,只是jdbc报了java.sql.SQLRecoverableException。那问题只能出在sqoop或jdbc的上
怀疑sqoop的问题,从以前客户端copy sqoop到新客户端,刚开始好了,再多次重试,又报错了。绝望
突然回想起来,以前解决过一个sqoop问题好像和jdk相关
回忆jdk,在调度机找到$JAVA_HOME/jre/lib/security/java.security,终于发现
当时把securerandom.source=file:/dev/urandom改为了securerandom.source=file:/dev./urandom
把所有客户端的jdk都改一下,发现问题不再重现,解决了!
那究竟是什么原因导致jdk 的这个系统参数会引发问题呢?
Jdk 连接oracle的时,从某个版本开始
The JDBC 11gneeds about 40 bytes of secure random numbers, gathered from /dev/random, toencrypt its connect string.
linux有两种类型随机数发生器,一个是/dev/random,一个是/dev/urandom,urandom=unlocked
random,即非阻塞随机。要产生真实的随机,linux是搜集真实的随机事件放到一个熵池里,当随机事件不足是,/dev/random会阻塞等到有随机事件产生才返回,而/dev/urandom则会重复利用以前的随机事件迅速返回。
那这里默认就是使用的/dev/urandom,为什么还是有问题呢?
因为这个版本的jdk,实际上在jdk代码里当匹配到/dev/urandom时实际上还是指向了/dev/random,于是大家就想到了一个变通办法采用/dev/./urandom,在linux系统中,加个点表示当前路径这个和之前一样,但是jdk代码却不不配,就绕过去了
从这个事件中的反思:
要重视bug的记录,便于长时间或者工作交接的问题追踪。磨刀不误砍柴工
碰到问题不可怕,要培养深入解决问题的习惯,深入解决问题就是提升的机会
而这次,我们临时要在新环境跑sqoop任务,只起了一个sqoop客户端,失败的概率特别高,所以找到这个问题的解决办法就显得异常急迫。我回顾一下当时的解决思路:
找dba沟通,明确问题确实不是出在oracle数据库那边,因为数据库的报错一定会返回ORA等异常,而这里明显没到数据库,只是jdbc报了java.sql.SQLRecoverableException。那问题只能出在sqoop或jdbc的上
怀疑sqoop的问题,从以前客户端copy sqoop到新客户端,刚开始好了,再多次重试,又报错了。绝望
突然回想起来,以前解决过一个sqoop问题好像和jdk相关
回忆jdk,在调度机找到$JAVA_HOME/jre/lib/security/java.security,终于发现
当时把securerandom.source=file:/dev/urandom改为了securerandom.source=file:/dev./urandom
把所有客户端的jdk都改一下,发现问题不再重现,解决了!
那究竟是什么原因导致jdk 的这个系统参数会引发问题呢?
Jdk 连接oracle的时,从某个版本开始
The JDBC 11gneeds about 40 bytes of secure random numbers, gathered from /dev/random, toencrypt its connect string.
linux有两种类型随机数发生器,一个是/dev/random,一个是/dev/urandom,urandom=unlocked
random,即非阻塞随机。要产生真实的随机,linux是搜集真实的随机事件放到一个熵池里,当随机事件不足是,/dev/random会阻塞等到有随机事件产生才返回,而/dev/urandom则会重复利用以前的随机事件迅速返回。
那这里默认就是使用的/dev/urandom,为什么还是有问题呢?
因为这个版本的jdk,实际上在jdk代码里当匹配到/dev/urandom时实际上还是指向了/dev/random,于是大家就想到了一个变通办法采用/dev/./urandom,在linux系统中,加个点表示当前路径这个和之前一样,但是jdk代码却不不配,就绕过去了
从这个事件中的反思:
要重视bug的记录,便于长时间或者工作交接的问题追踪。磨刀不误砍柴工
碰到问题不可怕,要培养深入解决问题的习惯,深入解决问题就是提升的机会
相关文章推荐
- Java性能分析及问题解决(二)jvm致命错误导致进程直接挂掉,错误日志分析及解决
- java.security.SecureRandom导致jetty、hadoop启动受阻问题
- java.security.SecureRandom导致jetty、hadoop启动受阻问题
- 一段RUBY的脚本,分析姓名的分数,本来没甚么难的,就是ruby1.91的编码问题,导致一堆问题。
- ICMP Redirect 报文导致TCP连接建立不起来的问题分析...
- 转载:VC运行库版本不同导致链接.LIB静态库时发生重复定义问题的一个案例分析和总结
- 注册表不能写入导致不能安装office问题分析
- VC运行库版本不同导致链接.LIB静态库时发生重复定义问题的一个案例分析和总结
- 频繁分配释放内存导致的性能问题的分析
- [百度分享]频繁分配释放内存导致的性能问题的分析
- 频繁分配释放内存导致的性能问题的分析
- [原]分析Vista导致资源管理器占用CPU资源100%的问题的原因及解决办法
- 多线程问题导致的JDBMonitor的bug分析
- 【百度分享】频繁分配释放内存导致的性能问题的分析
- Linux服务器丢弃window7的SYN导致三次握手无法完成的问题分析
- 使用PrintWriter对象导致Struts国际化化失败问题的解决及分析
- VC运行库版本不同导致链接.LIB静态库时发生重复定义问题的一个案例分析和总结
- VC运行库版本不同导致链接.LIB静态库时发生重复定义问题的一个案例分析和总结
- VC运行库版本不同导致链接.LIB静态库时发生重复定义问题的一个案例分析和总结
- 多线程问题导致的JDBMonitor的bug分析