codefollower

三者融合这样的想法，国外已经有一个开源实现了: SnappyData 官网: http://www.snappydata.io/ 源码: https://github.com/SnappyDataInc/snappydata 概述: https://blog.bcmeng.com/post/snappydata.html

整个 hadoop 生态圈中的开源项目真的能用琳琅满目来形容了，能想到的基本上都有了，不管是专用的还是集成出来的，应有尽有。 想做出能够脱颖而出的技术产品，唯有从算法、模型上做出理论突破了。

MySQL的事务实现倒也合理，默认事务隔离级别是REPEATABLE_READ，在这种隔离级别中运行的事务，如果执行的是select语句，就遵循REPEATABLE_READ，如果还包含update语句，从我的几个试验例子来看，对于update语句它用的是READ_COMMITTED并且为where子句中读到的记录加读锁。 ​​​​ 类似下面的例子可以猜出MySQL的事务实现方式，如果在另一个事务中更新pk=20的记录将被阻塞。 ```sql update tx_isolation_test set count = 100 where pk=10 and 10=(select count from (select count from tx_isolation_test where pk=20) as t); ```

**开源软件**: RocksDB **版本**: rocksdbjni-5.14.2.jar **问题**: org.rocksdb.RocksIterator 的反直觉设计与常见的 java.util.Iterator 不同 **细节描述**: 在 [Lealone-Plugins](https://github.com/lealone/Lealone-Plugins) 项目中集成 [RocksDB](https://github.com/facebook/rocksdb) 时，为了给上层查询数据，提供了一个 [RocksdbStorageMapCursor](https://github.com/lealone/Lealone-Plugins/blob/master/lealone-rocksdb/src/main/java/org/lealone/plugins/rocksdb/RocksdbStorageMapCursor.java) 类，它基于 RocksIterator 实现了 java.util.Iterator 接口，java.util.Iterator 的常规使用方式是先判断 hasNext()，如果为true再调用 next() 取到当前值，而 RocksIterator 是判断 isValid() 为true时就要把当前值取好，调用 next()...

**开源软件**: JDK/java.nio.channels 包 **版本**: 1.8或其他版本 **问题**: 如果执行 Selector.select 的线程阻塞了，其他执行 SelectableChannel.register 的线程也会阻塞 **细节描述**: 例如下面的代码会按 step 1到4 的顺序输出，而不是 step 1、step 2、step 4、step 3 ```java public static void main(String[] args) throws Exception {...

刚刚又踩了 NIO 的一个坑，排查了快两小时，找了各种原因才发现服务器端收到的字节数总是少于客户端要发送的，结果是因为调用了 java.nio.channels.SocketChannel.write 方法时，只是简单的channel.write(ByteBuffer) 了，这样调用可能只写了部分数据，要像这样用: ```java while (buffer.hasRemaining()) channel.write(buffer); ``` 为什么要这样设计？我都给你传一个ByteBuffer了，里面有pos，有limit，要写多少数据不会自己算吗？！

**做 Java 开发，是否有必要用 NIO 实现自己的网络客户端或网络服务器？** ### 简而言之，99%以上的场景都是没必要的。 用 NIO 实现一个成熟稳定的高性能的网络应用程序是一件很繁琐很容易出错的事，Java 开源社区已经有像 [Apache MINA](http://mina.apache.org/) 、[Netty](http://netty.io/) 和 [Vert.x](https://vertx.io/) 这样的网络框架或工具库了，直接拿了用就好了。 在 [Lealone-Plugins](https://github.com/lealone/Lealone-Plugins) 的网络层插件中就包含对 MINA、Netty 和 Vertx 的支持，不过我最近倒是心血来潮自己用 NIO 实现了一个用于 Lealone 数据库的[网络客户端和网络服务器](https://github.com/lealone/Lealone/tree/master/lealone-net/src/main/java/org/lealone/net/nio)。 之所以自己造了一个，是因为我在开发 Lealone...

**排查 drill 1.15.0 和 hadoop 2.7.4 问题的一个案例:** 在windows7下，最初跑drill的测试用例时一开始就报这个错但是没理: Area [xxxxxx] must be writable and executable for application user 然后我直接把**RemoteFunctionRegistry.createArea**里面的检查代码注释掉，临时解决了这个问题。 今天我下了drill的分发包来跑，执行sqlline.bat时又报这个错，我仔细看了看xxxxxx目录的权限都是可写可执行的呀为啥还报错。 我不得不去掉注释调试了代码才发现RemoteFunctionRegistry.createArea里面执行fileStatus.getOwner()时得出xxxxxx目录的Owner是Administrators，而ImpersonationUtil.getProcessUserName()是Administrator，少个s，调式ImpersonationUtil.getProcessUserName()的代码又跟到hadoop相关的UserGroupInformation.getLoginUser()，hadoop默认又取jdk标准库返回的Administrator，所以就出错了。 还好UserGroupInformation.getLoginUser()允许通过设置环境变量HADOOP_PROXY_USER来指定代理用户名，把它设成Administrators就解决了。 之所以fileStatus.getOwner()返回Administrators，我跟踪了代码，发现在org.apache.hadoop.fs.RawLocalFileSystem.DeprecatedRawLocalFileStatus.loadPermissionInfo() 里面它用了winutils.exe ls -F xxxxxx命令得到了一个"drwx------|1|BUILTIN\Administrators..."这样的字符串，然后Owner就变成了Administrators，也就是它取了管理员用户组去了。

**将现有 Java 代码用 Kotlin 重写后并不是每个项目的代码量都能减少 30%** 以 jsoup 为例，用 IntelliJ IDEA 2018.1.1 (Community Edition) 转成 Kotlin 后，Java 版的核心代码是 680kb，而 Kotlin 版的是 650kb，只少了 30kb，连个零头都不到。 还试了另一个 Java 开源项目: jericho-html，转成 Kotlin 后代码量也没降多少。 单纯拿...

**不要指望把现有的 Java 代码自动转成 Kotlin 后没有任何错误** 把 jsoup、 jericho-html 这两个 Java 项目转成 Kotlin 后就存在大量的错误。