php文件夹nofoollw,defool ( Defoo Li )

最新推荐文章于 2021-08-04 09:12:48 发布

投必得论文编译

最新推荐文章于 2021-08-04 09:12:48 发布

阅读量173

点赞数

文章标签： php文件夹nofoollw

This PR fixes the following problems:

run go fmt against the code base

fix several problems identified by go vet, such as unreachable code, broken tests, missing struct field names.

bump openzipkin-contrib/zipkin-go-opentracing to v0.4.5, fix broken plugin

fix typo, zombile to zombie

+83 -94

comment

22 changed

files

pr created time in 16 hours

started time in a day

We experienced a problem due to fd leak on server side. Here is the detail:

When client send requests with packet size greater than MaxPackageLength which result in a PACKAGE_ERROR on server side

Server close the connection by calling (*net.TCPConn).Close()

But the connection is NOT closed since we make a copy of the underlying fd in (*transport.tcpHandler).Handle

All subsequent requests from the client on the same connection failed with timeout error

This could result in:

run out of fd on server side

DoS if the client is also a Tars server which is the situation we faced

closed time in 2 days

chenhengqi

defool

commit sha774454b153f360d2e15a325035e0eddb21f497ec

fix: close fd when close connection

Signed-off-by: chenhengqi

commit sha4ba232594bb32b3ae3be77d8892a36d7bfc13194

Merge pull request #274 from chenhengqi/fix-fd-leak

fix: close fd when close connection

push time in 2 days

This PR aims to resolve the problem mentioned in #273

Signed-off-by: chenhengqi chenhengqi@outlook.com

+1 -0

comment

1 changed

file

chenhengqi

defool

pr closed time in 2 days

created repositorygocn/cool-go

深度解析推荐 Go 框架, 库和软件的用途、场景等

created time in 4 days

This PR aims to resolve the problem mentioned in #273

Signed-off-by: chenhengqi chenhengqi@outlook.com

+1 -0

comment

1 changed

file

pr created time in 10 days

We experienced a problem due to fd leak on server side. Here is the detail:

When client send requests with packet size greater than MaxPackageLength which result in a PACKAGE_ERROR on server side

Server close the connection by calling (*net.TCPConn).Close()

But the connection is NOT closed since we make a copy of the underlying fd in (*transport.tcpHandler).Handle

All subsequent requests from the client on the same connection failed with timeout error

This could result in:

run out of fd on server side

DoS if the client is also a Tars server which is the situation we faced

created time in 10 days

add remote default value

+0 -0

comment

0 changed

file

lanhy

defool

pr closed time in 12 days

add remote default value

+0 -0

comment

0 changed

file

pr created time in 12 days

commit shae2acd62e4abed76f24df45ba541a701effdd736a

Merge pull request #1 from TarsCloud/master

sync code from master

commit sha298083a577132472ad0f6e1b07e39094065c97b2

add remote default value

commit sha26a06ecd0a2b89b084f33c51560ce296e8c6206d

Merge pull request #269 from lanhy/feature_remotelog

Feature remotelog

push time in 12 days

远程日志缺省格式设置

+6 -0

comment

1 changed

file

lanhy

defool

pr closed time in 12 days

发现接口函数没有开启新groutine，panic后也会导致整个进程的panic。

查看框架内部实际上在invoke的时候是有调用CheckPanic的，https://github.com/TarsCloud/TarsGo/blob/master/tars/tarsprotocol.go#L36。但是这个CheckPanic函数会直接exit，没有达到recover的效果，和请求分发在同一个groutine的panic是否也需要业务方自己recover，例如在filter中进行recover

created time in 13 days

commit sha93d5e1647a68ca1fd924039d98a052c05543b4c8

fix: JSON number loss of precision

commit sha01290004d6aea20c4731b792ead58474ba400750

Merge pull request #270 from chenhengqi/fix/json-number-precision

fix: JSON number loss of precision

push time in 13 days

https://github.com/TarsCloud/TarsGo/blob/7301d63348a7d80d3c26eb21f90e5473d132e37f/tars/tools/tars2go/gen_go.go#L1467-L1468

具体问题和解决办法参考：https://zhuanlan.zhihu.com/p/114286134

建议修复一下

closed time in 13 days

tzwsoho