dataminor

I saw many comments saying that the file write stream is not recoverable automatically. Will the fixing be scheduled in the near future?

I think this package is the 'native' hdfs client package for golang and it will be very nice if you can add the failover recovery part. For the retrying, do...

Hi, @colinmarc . I took your advice and use reopening to retry, but got the following error constantly: ``` 2017/08/25 03:26:00.320699 file_writer.go:108: [INFO] Close error:updateBlockForPipeline call failed with ERROR_APPLICATION (java.io.IOException)...

> pthread mutex 里有线程 id的字段，可以看看持有锁的线程在做什么 这样的。有挺多的栈，分成了两种，1类型的栈的pthread mutex里的owner是2类型的栈的线程所持有的，在我的问题中我标注了一下类型。 我们的机器是32核的，正好有32个类型是1的栈都卡住了，分别去等多个类型是2的栈持有的锁 我理解堆积是因为这些堆积的bthread也要去拿同一把锁导致的

- > 本质上是这个问题：[apache/incubator-brpc#473](https://github.com/apache/incubator-brpc/issues/473) 。可以先切换成 bthread mutex 试试 ，参见 macros.h： > > //#define USE_BTHREAD_MUTEX > > 使用 bthread mutex 后，类型 1 的栈会在类型 2 后排队，可以让用于执行 bthread 的线程更多，不造成堆积的话，也就不会有这种死锁 case 多谢解答！ 我试了下去掉这个注释，但看起来还需要别的修改，因为log.h里用到butil里的东西，而那边是用的butil::Mutex，具体编译错误如下： `In file...

> 我本地可以编译过，你们改代码了？butil和bthread下各有一个ConditionVariable，用bthread命名空间下的就可以了 多谢，我们是有做一些代码的修改，现在已经能够编译通过，并用bthread_mutex代替pthread_mutex做了一下验证，发现仍然有可能导致死锁的问题。 我理解在_rq full时，如果在_rq里所有换出的bthread拿的锁恰好是当前正在执行的bthread里所需要拿的锁，就可能发生死锁的情况，不知道我理解得对不对。这里如果想要彻底解决这个问题，就需要避免_rq full的时候换出的bthread持有的锁是正在执行的bthread要拿的锁这种情况。不知道是否有比较好的办法可以从根本上解决这个问题？ 还有一个问题想请教一下，bthread_mutex里的mutex是一个unsigned int，没有标识线程信息，这里拿到了这个unsigned int之后如何去找谁持有了这个mutex呢？

> > > > 我本地可以编译过，你们改代码了？butil和bthread下各有一个ConditionVariable，用bthread命名空间下的就可以了 > > > > > > > > > 多谢，我们是有做一些代码的修改，现在已经能够编译通过，并用bthread_mutex代替pthread_mutex做了一下验证，发现仍然有可能导致死锁的问题。 > > > 我理解在_rq full时，如果在_rq里所有换出的bthread拿的锁恰好是当前正在执行的bthread里所需要拿的锁，就可能发生死锁的情况，不知道我理解得对不对。这里如果想要彻底解决这个问题，就需要避免_rq full的时候换出的bthread持有的锁是正在执行的bthread要拿的锁这种情况。不知道是否有比较好的办法可以从根本上解决这个问题？ > > > 还有一个问题想请教一下，bthread_mutex里的mutex是一个unsigned int，没有标识线程信息，这里拿到了这个unsigned int之后如何去找谁持有了这个mutex呢？ > > >...

> 流控可以依赖pending的任务数量（自己在代码里用bvar统计，或者检查status页面rpc请求的processing的统计）来做，这里的case，应该会有一个不断增加的过程 多谢 @PFZheng 我们在考虑流控的事情，但我这里有一个小疑问，现在我们用的是bthread mutex了，但仍然死锁，查看死锁的线程栈，发现有如下几种： 1 `Thread 113 (Thread 0x7f7117fff700 (LWP 30422)): #0 0x00007f840ece6419 in syscall () from /lib64/libc.so.6 #1 0x0000000000de7dd2 in futex_wait_private (pw=..., ptimeout=0x0) at /home/zhangbiao11/Code/mraft/mraft/deps/incubator-brpc/src/bthread/sys_futex.h:42 #2 bthread::wait_pthread...

> 你们是开启了 usercode_in_pthread或者混用了其他的线程池? futex_wait_private 这个说明是在普通pthread线程里持有了锁，这个时候butex会退化成futex。如果是混用了其他的线程池，可以主动发起一个bthread去执行操作，切换到bthread线程池里 我看了下，braft里面唯一让用户去控制usercode_in_pthread的地方就是在创建node的时候init()函数传入的option，这个option我们没有去设置usercode_in_pthread这个值，我看默认值是false的。所以我们应该没有开启usercode_in_pthread。 我们其实没有直接地使用bthread，都是通过braft来间接使用bthread的。我们对braft的使用其实蛮简单的，就只会调用apply接口以及实现state_machine的on_apply等回调 我们的服务里是会有别的线程，但是这些线程不会和braft bthread有关

> braft::SegmentLogStorage::get_segment (this=0x7f6f7d45af70, group_id=12638, index=62666) 看起来根源是这个锁，这里有做改动吗？ > > 这儿有个嵌套。replicator 的 bthread id lock 里会去拿 Segment 的锁。Node 里有周期性的定时器会拿 replicator的 bthread id lock（获取 last_rpc_send_timestamp），Segment 锁住会造成整个 node 的锁竞争。这个地方目前在内部版本已经改了，还没同步过来。不过这个锁竞争仍然是 butex 的，不应该占住线程，主要还是看 get_segment 为什么会锁住。 我们对写日志这块有一些优化，是改过code的