0xZensh
0xZensh
Teambition 文件服务 https://striker.teambition.net/ 使用 [toa](https://github.com/toajs/toa) 编写。OSS 是其存储源之一。完善了日志分析服务之后，我们发现该服务有一定概率出现异常： ``` json {"name":"ResponseError","message":"socket hang up (req \"error\")} ``` 经过 @orangemi 同学的一番 debug 后终于找到了原因： 我们使用了 oss sdk 的 `getStream` 方法读取文件流，直接 pipe 给客户端的 response，代码大概如下： ```...
会~，只是可能性极小了，得找个万全之策
没有对比测过 keepalvie 对来的效益。想了下，response error 的情况下 destroy oss stream 是不会出现问题的，因为这个 socket 肯定还是在为这一单服务，不可能接其他单
搞个 passthrough 中介的话，且不说性能消耗，还要处理异常传递，不美~
昨晚上的，暂时没有了
@gxcsoccer 因为都在阿里云上，走的是内网，所以没那些问题。destroy，keepaliveagent 会自动补上，问题是 destroy 时误杀了正常的 stream
@dead-horse 这也是个原因，不过也好处理了， 那么要考虑重复 set body 和错误响应，都需要确保 close stream
我认为 set body 中不应该做这个事，否则考虑各种情况会变得很复杂，这个要放在 respond 和 error handle 中去做
toa 利用自有的逻辑修复了下：https://github.com/toajs/toa/commit/2633f5e47810a9f243e8ddfa578b472445008ff8#diff-910eb6f57886ca16c136101fb1699231R737 主要有如下几点： 1. onerror 分两个层级，app.onerror 和 ctx.onerror，前者是顶级 error 监听，用于写日志，后者是 context 级 error 监听，拿到 error 后会尝试响应客户端，然后丢给 app.onerror 处理 2. ctx.catchStream 方法会对 stream 添加 ctx.onerror，执行后会卸载监听，如果存在 error 会 destroy stream，但卸载后会保证 app.onerror 监听。像...
https://github.com/fxamacker/cbor/blob/5cd39e10d523e537553c37fbf35187b537664706/valid.go#L76 ```go _, err := d.validInternal(0) if err == nil && len(d.data) != d.off { err = &SyntaxError{"cbor: unexpected following extraneous " + strconv.Itoa(len(d.data)-d.off) + " bytes"} } return err...