vearne / grpcreplay

GrpcReplay is an open-source network monitoring tool which can record your grpc traffic and use it for shadowing, load testing, monitoring and detailed analysis.
MIT License
13 stars 3 forks source link

method is empty, this is illegal for restart of grpc client #50

Open fireblackman opened 6 days ago

fireblackman commented 6 days ago

2024/09/18 18:00:27 [error] method is empty, this is illegal 2024/09/18 18:00:27 [debug] Http2Conn.deal, Connection:192.168.3.52:34478 -> 192.168.11.239:6789 2024/09/18 18:00:27 [debug] Http2Conn.deal, ParseFrameBase, Connection:192.168.3.52:34478 -> 192.168.11.239:6789 2024/09/18 18:00:27 [debug] Connection:192.168.3.52:34478 -> 192.168.11.239:6789, FrameType:FrameWindowUpdate, streamID:0, len(payload):4 2024/09/18 18:00:27 [debug] ignore Frame:FrameWindowUpdate 2024/09/18 18:00:27 [debug] Http2Conn.deal, Connection:192.168.3.52:34478 -> 192.168.11.239:6789

After my test, the problem with close and restart the client without the grpc server and record service. it should be a bug, and it seems that the recording service failed to effectively identify the closing and reconnection of the tcp connection. i had send log to your email. about three reboots will appear once. then must restart the grpc server and capture service. More clients. This will be a problem.

fireblackman commented 6 days ago

Later, I'll test with 100 to 200 clients, which will have about 50,000 concurrent transactions per second. I don't know if there will be performance problems, which remains to be analyzed.

vearne commented 6 days ago

2024/09/18 18:00:27 [error] method is empty, this is illegal 2024/09/18 18:00:27 [debug] Http2Conn.deal, Connection:192.168.3.52:34478 -> 192.168.11.239:6789 2024/09/18 18:00:27 [debug] Http2Conn.deal, ParseFrameBase, Connection:192.168.3.52:34478 -> 192.168.11.239:6789 2024/09/18 18:00:27 [debug] Connection:192.168.3.52:34478 -> 192.168.11.239:6789, FrameType:FrameWindowUpdate, streamID:0, len(payload):4 2024/09/18 18:00:27 [debug] ignore Frame:FrameWindowUpdate 2024/09/18 18:00:27 [debug] Http2Conn.deal, Connection:192.168.3.52:34478 -> 192.168.11.239:6789

After my test, the problem with close and restart the client without the grpc server and record service. it should be a bug, and it seems that the recording service failed to effectively identify the closing and reconnection of the tcp connection. i had send log to your email. about three reboots will appear once. then must restart the grpc server and capture service. More clients. This will be a problem.

Client restart does cause problems. This is because I did not handle Fin packets in the current version. Grpc uses http2, and the dynamic table of http2 is associated with a single connection. Therefore, to ensure normal parsing, the dynamic table needs to be reinitialized after the connection is reestablished. I will deal with it later. Maybe tomorrow.

vearne commented 5 days ago

2024/09/18 18:00:27 [error] method is empty, this is illegal 2024/09/18 18:00:27 [debug] Http2Conn.deal, Connection:192.168.3.52:34478 -> 192.168.11.239:6789 2024/09/18 18:00:27 [debug] Http2Conn.deal, ParseFrameBase, Connection:192.168.3.52:34478 -> 192.168.11.239:6789 2024/09/18 18:00:27 [debug] Connection:192.168.3.52:34478 -> 192.168.11.239:6789, FrameType:FrameWindowUpdate, streamID:0, len(payload):4 2024/09/18 18:00:27 [debug] ignore Frame:FrameWindowUpdate 2024/09/18 18:00:27 [debug] Http2Conn.deal, Connection:192.168.3.52:34478 -> 192.168.11.239:6789

After my test, the problem with close and restart the client without the grpc server and record service. it should be a bug, and it seems that the recording service failed to effectively identify the closing and reconnection of the tcp connection. i had send log to your email. about three reboots will appear once. then must restart the grpc server and capture service. More clients. This will be a problem.

use v0.2.2 and try again. @fireblackman

fireblackman commented 5 days ago

After my test, this issue did not occur with the single client connection. but when I reconnect with two clients, there is still a high chance of this problem. i had send log to your email.

fireblackman commented 2 days ago

If you have time, please you can look at this problem. Thank you. I am also learning the development way of go, but I can not get started soon. I can donate it. It is a very good project. with best wishes.

vearne commented 1 day ago

If you have time, please you can look at this problem. Thank you. I am also learning the development way of go, but I can not get started soon. I can donate it. It is a very good project. with best wishes.

Thanks for using grpcreplay. Maybe you are the first person to actually use it. donate

vearne commented 1 day ago

After my test, this issue did not occur with the single client connection. but when I reconnect with two clients, there is still a high chance of this problem. i had send log to your email.

Last Friday, I tried to reproduce this problem, but failed. Please provide a detailed step-by-step guide to reproduce this problem. I suspect that my implementation of the transport layer may be flawed.

fireblackman commented 1 day ago

This problem occurs with the almost same time restart of the two client. if i has 100 clients, it will take long time. I'm not in a hurry. watch it when you have the time.