我的HBase版本是1.1.3,在进行scan时候抛出ScannerTimeoutException异常，具体如下：
Exceptioninthread”main”java.lang.RuntimeException:org.apache.hadoop.hbase.client.ScannerTimeoutException: 143538ms passed since the last invocation, timeout is currently set to 60000
这个是异常是说连接超时，大于默认的1分钟，在网上百度了一下，有很多的解决方法，其中最多的就是把这个值改的大一些，如下
config.setLong(HConstants.HBASE_REGIONSERVER_LEASE_PERIOD_KEY,300000);
用这个方法你会发现已经过时，但是还能用，先将就用吧！
相关文章
- java 调用 docker 中的 HBase 服务 卡死 不报错 不报异常 卡着不动 但 服务ip是能ping通
- ASP.NET程序中 抛出"Thread was being aborted. "异常（转）
- java中抛出异常快捷键_idea中处理异常的快捷键
- spark2.1注册内部函数spark.udf.register("xx", xxx _)，运行时抛出异常：Task not serializable
- java异常处理 throw RuntimeException时不需要同时方法中声明抛出throws 异常等待调用者catch进行捕获 子父类异常问题
- Swift 中异常抛出和四种异常处理
- Redis --- redis事务和分布式事务锁-事务过程中失败有两种可能： Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令中用在了错误类型的键上面，所以如果在生产环境中你使用的正常命令，那么在 Redis 事务中，是不会出现错误而导致回滚的。 来自文档：Redis commands can fail only if called with a wrong syntax... 事务执行一半，Redis宕机。如果 Redis 服务器因为某些原因被管理员杀死，或者遇上某种硬件故障，那么可能只有部分事务命令会被成功写入到磁盘中。如果 Redis 在重新启动时发现 AOF 文件出了这样的问题，那么它会退出，并汇报一个错误。使用redis-check-aof程序可以修复这一问题：它会移除 AOF 文件中不完整事务的信息，确保服务器可以顺利启动 注意： 若在事务队列中存在命令性错误（类似于java编译性错误），则执行EXEC命令时，所有命令都不会执行 若在事务队列中存在语法性错误（类似于java的1/0的运行时异常），则执行EXEC命令时，其他正确命令会被执行，错误命令抛出异常。 Redis 官网也解释了自己为啥不支持回滚。简单来说就是 Redis 开发者们觉得没必要支持回滚，这样更简单便捷并且性能更好（回滚还需要解决回滚事务覆盖的问题）。Redis 开发者觉得即使命令执行错误也应该在开发过程中就被发现而不是生产过程中。
- [改善Java代码]不要在构造函数中抛出异常
- 【甘道夫】HBase开发环境搭建过程中可能遇到的异常：No FileSystem for scheme: hdfs
- 【Java学习笔记之三十二】浅谈Java中throw与throws的用法及异常抛出处理机制剖析