alexstocks / getty Goto Github PK

如题，没有找到func (p *TaskPool) start()使用

Hello,I have some questions about net.reader.read method in "transport/session.go" and "transport/connection.go" , when you send a tcp pkg,getty how to recognize the length of this tcp pkg?and that if the recv pkg > 4096 bytes ? how does getty to handle such situation?

`// Write multiple packages at once. so we invoke write sys.call just one time.
func (s *session) WriteBytesArray(pkgs ...[]byte) error {
if s.IsClosed() {
return ErrSessionClosed
}
// s.conn.SetWriteTimeout(time.Now().Add(s.wTimeout))
if len(pkgs) == 1 {
// return s.Connection.Write(pkgs[0])
return s.WriteBytes(pkgs[0])
}

// reduce syscall and memcopy for multiple packages
if _, ok := s.Connection.(*gettyTCPConn); ok {
       // 第一次发送
	if _, err := s.Connection.send(pkgs); err != nil {
		return jerrors.Annotatef(err, "s.Connection.Write(pkgs num:%d)", len(pkgs))
	}
}

// get len
var (
	l      int
	err    error
	length int
	arrp   *[]byte
	arr    []byte
)
length = 0
for i := 0; i < len(pkgs); i++ {
	length += len(pkgs[i])
}

// merge the pkgs
//arr = make([]byte, length)
arrp = gxbytes.GetBytes(length)
defer gxbytes.PutBytes(arrp)
arr = *arrp

l = 0
for i := 0; i < len(pkgs); i++ {
	copy(arr[l:], pkgs[i])
	l += len(pkgs[i])
}
 // 第二次发送
if err = s.WriteBytes(arr); err != nil {
	return jerrors.Trace(err)
}

num := len(pkgs) - 1
for i := 0; i < num; i++ {
	s.incWritePkgNum()
}

return nil

}
`

TCP模式下，pkgs数量超过1，那么数据包会被发送两次

What would you like to be added:
提供指定http.Server的ErrorLog功能

Why is this needed:
http.Server的错误日志默认会写到标准输出，但它提供了指定自定义Logger的口子，getty似乎没有开放这个口子？

http\server.go

type Server struct {
        // ErrorLog specifies an optional logger for errors accepting
	// connections, unexpected behavior from handlers, and
	// underlying FileSystem errors.
	// If nil, logging is done via the log package's standard logger.
	ErrorLog *log.Logger
}

getty\options.go

type ServerOptions struct {
	addr string
	// tls
	sslEnabled       bool
	tlsConfigBuilder TlsConfigBuilder
	// websocket
	path       string
	cert       string
	privateKey string
	caCert     string
	// task queue
	tPool gxsync.GenericTaskPool
}

让micro server的conf中每个端口、codec 协议、service、version等绑定起来

in handleLoop() function select case <-s.done: branch

counter.Start()
if counter.Count() > s.wait.Nanoseconds() {
  log.Info("%s, [session.handleLoop] got done signal ", s.Stat())
  break LOOP
}

if counter doesn't reach session exit waiting time , this if-branch will not hit so it cannot break loop.
however close(s. done) will tigger only once, if for-loop continue running ,case <-s.done will never reach.
so exit wait delay will not perform as expected.

In my opinion, judging exit waiting timeout should appear in select default case or using while counter.Count() > s.wait.Nanoseconds() {} to confirm timeout exit as expected.

What would you like to be added:
To resolve this problem, it is necessary to modify all the functions defined in getty.Connection to be exported with uppercase names.

Why is this needed:
Seata-go references getty, and encountered obstacles when writing unit tests related to the getty.Session interface. Neither gomock nor gomonkey can mock the getty.Session interface.

The issue arises from the fact that the getty.Connection interface defines lowercase unexported functions, and the getty.Session interface composes getty.Connection, making it impossible to mock getty.Session from outside the getty package.

connection.go中 func (w *gettyWSConn) recv() ([]byte, error){}方法内疑似缺失
atomic.AddUint32(&conn.readBytes, uint32(len(b))) 累加wsConn中对readBytes的计数

将compress_encoding设置成false，tcp_read_timeout设置成5s。
经过debug发现，conn.go line 252会返回read tcp xxx:xxx->xxx:xxx: i/o timeout的错误。实际的read时间，大概只有2s多一点，并不是tcp_read_timeout设置的5s。

there are lot of code that need to consider what kind of the connection, tcp or udp or ws, which let the code logic complex.

So suggest to separate udp/tcp/ws code logic.

For example, a interface can be defined:

type ProtocolHandler interface {
     handleLoop()
     handlePackage()
}

Assign matched ProtocolHandler to a protocol, not check the type of connection in handler logic, make the logic simple.

我在模仿tcp-echo服务的时候有一个关于SessionNumber的疑问：
当有新连接连接成功时：func newSession(session getty.Session) error 被调用，对于getty.Session对象调用了SetEventListener方法，参数通过newEchoMessageHandler创建EchoMessageHandler。EchoMessageHandler中的sessionMap同时被初始化。此后func (h *EchoMessageHandler) OnOpen(session getty.Session)被调用。而后续的新连接都会调用newEchoMessageHandler并创建自己的sessionMap。我理解的sessionMap应当是系统支持的最大连接数，这样设计是不是不合理。

Welcome to use getty. To know who is using it, pls append your org info as follow,

• Organization：Alibaba (Required)
• Location: Hangzhou, Zhejiang, China（Required）
• Contact: [email protected] (Optional)
• Purpose：used as our fundamental network transport lib (Required)
• Transport Protocol: TCP（Required）
• Version: alexstocks/getty v1.5.5 or apache/dubbo-getty v1.5.5（Required）
• Com/Org Logo：(Optional)
  Thanks again for your participation!

欢迎使用 getty，首先感谢你的使用，其次您可以参考下面的样例来提供您的信息以收集下使用场景：

* 组织：阿里巴巴（Required）
* 地点：**杭州（Required）
* 联系方式：[email protected]（Optional）
* 场景：作为基础通信库使用（Required）
* 通信协议: TCP（Required）
* 版本: alexstocks/getty v1.5.5 或者 apache/dubbo-getty v1.5.5（Optional）
* 公司图标：（Optional）

再次感谢你的参与!!!

当程序发生panic进入handleLoop的defer代码块中，执行gc方法后，会导致如图三的空指针panic

If you r going to wait response,or block the goroutine in a getty session(tcp conection), task pool can not be null。

func (s *Server) newSession(session getty.Session) error {
	var (
		ok      bool
		tcpConn *net.TCPConn
	)
	
	// 省略部分代码...
	session.SetTaskPool(srvGrpool)
	return nil
}

ortherwise,handleTcpPackage() will blocked,led to the response missing

func (s *session) addTask(pkg interface{}) {
	f := func() {
		s.listener.OnMessage(s, pkg)
		s.incReadPkgNum()
	}
	if s.tPool != nil {
		s.tPool.AddTask(f)
		return
	}
	f()
}

What happened: 服务端主动关闭连接时，返回的错误码及错误信息异常

What you expected to happen:客户端得到正确的错误码和错误信息

How to reproduce it (as minimally and precisely as possible): 使用master分支的代码，服务端主动关闭连接，100%出现

Anything else we need to know?:

At present, the rpc means that only the server can receive request from client and then send back its response. However, the client can not handle the request from the server.

To handle request from server, the client should register its callback. what's more, we have an agreement that the sequence in the request package from the client should be an odd number and the sequence in the request package from server is an even number.

What would you like to be added:

improve the log in this way:

if  logLevel >= log.INFO  { 
    log.Info(...) 
}

Why is this needed:

Improve the performance.

➜ echo_server--20210918-1516-test git:(master) ✗ pwd
................./getty/examples/echo/tcp-echo/server/target/darwin/echo_server--20210918-1516-test
➜ echo_server--20210918-1516-test git:(master) ✗ sh bin/load_echo_server.sh start
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0xb01dfacedebac1e pc=0x7fff65d50476]

runtime stack:
runtime: unexpected return pc for runtime.sigpanic called from 0x7fff65d50476
stack: frame={sp:0x70000bcf8e58, fp:0x70000bcf8ea8} stack=[0x70000bc79338,0x70000bcf8f38)
0x000070000bcf8d58: 0x010070000bcf8d78 0x0000000000000004
0x000070000bcf8d68: 0x000000000000001f 0x00007fff65d50476
0x000070000bcf8d78: 0x0b01dfacedebac1e 0x0000000000000001
0x000070000bcf8d88: 0x00000000040370b1 <runtime.throw+0x0000000000000071> 0x000070000bcf8e28
0x000070000bcf8d98: 0x000000000439db39 0x000070000bcf8de0
0x000070000bcf8da8: 0x0000000004037368 <runtime.fatalthrow.func1+0x0000000000000048> 0x000000c000001520
0x000070000bcf8db8: 0x0000000000000001 0x0000000000000001
0x000070000bcf8dc8: 0x000070000bcf8e28 0x00000000040370b1 <runtime.throw+0x0000000000000071>
0x000070000bcf8dd8: 0x000000c000001520 0x000070000bcf8e18
0x000070000bcf8de8: 0x00000000040372f0 <runtime.fatalthrow+0x0000000000000050> 0x000070000bcf8df8
0x000070000bcf8df8: 0x0000000004037320 <runtime.fatalthrow.func1+0x0000000000000000> 0x000000c000001520
0x000070000bcf8e08: 0x00000000040370b1 <runtime.throw+0x0000000000000071> 0x000070000bcf8e28
0x000070000bcf8e18: 0x000070000bcf8e48 0x00000000040370b1 <runtime.throw+0x0000000000000071>
0x000070000bcf8e28: 0x000070000bcf8e30 0x00000000040370e0 <runtime.throw.func1+0x0000000000000000>
0x000070000bcf8e38: 0x00000000043a3f42 0x000000000000002a
0x000070000bcf8e48: 0x000070000bcf8e98 0x000000000404d6d6 <runtime.sigpanic+0x0000000000000396>
0x000070000bcf8e58: <0x00000000043a3f42 0x000070000bcf8e80
0x000070000bcf8e68: 0x000070000bcf8ed8 0x0000000004028506 <runtime.(*mheap).allocSpan+0x0000000000000546>
0x000070000bcf8e78: 0x000000c00009c000 0x0000000000002000
0x000070000bcf8e88: 0x000000c000000008 0x0000000000000000
0x000070000bcf8e98: 0x000070000bcf8ee0 !0x00007fff65d50476
0x000070000bcf8ea8: >0x000070000bcf8ee0 0x00000000045e7000
0x000070000bcf8eb8: 0x0000000000000420 0x00000000040d2f85 <golang.org/x/sys/unix.libc_ioctl_trampoline+0x0000000000000005>

The function rpcClientArray.Put should check gettyRPCClient exist in rpcClientArray.array or not before putting is into rpcClientArray.array.

func (a *rpcClientArray) Put(clt *gettyRPCClient)

What would you like to be added:

Here are some possible reasons for the closure:

1000: Normal closure
1001: Going away
1002: Protocol error
1003: Unsupported data
1004: Too large frame
1005: No extension
1006: Invalid frame payload
1007: Policy violation
1008: Message too large
1009: Internal server error
1010: TLS handshake failure

Why is this needed:

micro client 关闭时候退出log如下：

[2018/08/18 13:55:51 CST] [DEBG] (filter.go:github.com/AlexStocks/goext/database/filter/pool.(*Filter).watch:210) watch.Notify() = result{nil}, error{&errors.unformatter{message:"watcher stopped", cause:error(nil), previous:error(nil), file:"github.com/AlexStocks/goext/database/registry/zookeeper/watcher.go", line:345}}
[2018/08/18 13:55:51 CST] [DEBG] (filter.go:github.com/AlexStocks/goext/database/filter/pool.(*Filter).run:176) services.watch(w) = err{"github.com/AlexStocks/goext/database/registry/zookeeper/watcher.go:345: watcher stopped"}
[2018/08/18 13:55:51 CST] [WARN] (filter.go:github.com/AlexStocks/goext/database/filter/pool.(*Filter).run:178) Filter.watch() = error{github.com/AlexStocks/goext/database/registry/zookeeper/watcher.go:345: watcher stopped}
[2018/08/18 13:55:54 CST] [WARN] (filter.go:github.com/AlexStocks/goext/database/filter/pool.(*Filter).run:155) (Filter)run() isClosed now
[2018/08/18 13:55:54 CST] [EROR] (main.go:main.initSignal.func1:96) app exit now by force...

micro server和micro client都启动后，server有如下错误log：

[2018/08/18 13:24:26 CST] [EROR] (session.go:github.com/AlexStocks/getty.(*session).handlePackage.func1:553) {getty-micro-server:TCP_SERVER:1:127.0.0.1:20000<->127.0.0.1:58960}, [session.handlePackage] error{github.com/AlexStocks/getty/rpc/readwriter.go:58: request service is nil
github.com/AlexStocks/getty/session.go:653: }

Before v1.12 the fd.Writev of golang have a fatal bug,
so I send multiple byte steam packages by merging them. However, the latest golang version v1.14.1 has released, I think getty should use writev now.

there are two funcs which can use writev:

1 session.go:session.WriteBytesArray
2 session.go:session.handleLoop

• 底层使用epoll + 事件驱动编程模型，替代golang默认的epoll + 协程阻塞编程模型。
• 开关配置，用户可根据自身的场景，决定使用何种协程模型。