Conversation
|
|
|
|
42bc4fe to
6dad6bb
Compare
|
6dad6bb to
647bea1
Compare
|
|
1 similar comment
|
|
|
|
|
|
|
|
This looks like a good start. Reviewed 26 of 35 files at r1, 11 of 13 files at r2, 4 of 4 files at r4. src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 48 at r4 (raw file):
Consider using the C++ filter API, defined in src/cpp/common/channel_filter.h. src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 67 at r4 (raw file):
Suggest removing the src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 70 at r4 (raw file):
No, you can't use that on the server side. That field is only set on the client side. The server side doesn't know the path at call construction time; it only knows it when it gets the recv_initial_metadata op. src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 90 at r4 (raw file):
Shouldn't this be renamed to something like Can we tell this by checking that one of the fields above (e.g., original_recv_initial_metadata_ready) is non-null, rather than having a separate bool for it? src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 105 at r4 (raw file):
Please use src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 198 at r4 (raw file):
The host can be different per call if virtual hosting is in use. Most people don't do that with grpc, though. src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 245 at r4 (raw file):
It's safe to use RUN here, since this is the end of a closure, and we can be sure no locks are being held. src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 259 at r4 (raw file):
No need for this memset(). Filter memory is always initialized to zero for you by the channel stack. Comments from Reviewable |
|
Thanks for the early review! Review status: all files reviewed, 8 unresolved discussions (waiting on @markdroth, @dgquintas, and @summerxyt) src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 48 at r4 (raw file): Previously, markdroth (Mark D. Roth) wrote…
Done. src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 67 at r4 (raw file): Previously, markdroth (Mark D. Roth) wrote…
Done. src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 70 at r4 (raw file): Previously, markdroth (Mark D. Roth) wrote…
Deleted. Pinged bdrutu internally. src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 90 at r4 (raw file): Previously, markdroth (Mark D. Roth) wrote…
Done. Using src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 105 at r4 (raw file): Previously, markdroth (Mark D. Roth) wrote…
Done. My IDE keeps telling me to use src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 198 at r4 (raw file): Previously, markdroth (Mark D. Roth) wrote…
Got it. src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 245 at r4 (raw file): Previously, markdroth (Mark D. Roth) wrote…
Done. src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 259 at r4 (raw file): Previously, markdroth (Mark D. Roth) wrote…
I see. Yeah, the call stack is allocated from arena, which is Comments from Reviewable |
|
|
|
|
|
|
|
Looks like this is moving in the right direction! Reviewed 4 of 6 files at r5, 4 of 4 files at r6. src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 105 at r4 (raw file): Previously, AspirinSJL (Juanli Shen) wrote…
The style guide says to only use I personally prefer to make const-ness and pointer/reference types explicit in conjunction with src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 93 at r6 (raw file):
Please use C++ style here: no need for the src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 95 at r6 (raw file):
Seems weird to have a struct element declared as an array with no size. Maybe make this a pointer instead? src/cpp/common/channel_filter.h, line 210 at r6 (raw file):
This doesn't seem like quite the right API, because the peer string is handled as part of the send_initial_metadata op on the client side and part of the recv_initial_metadata op on the server side. So I think we need to either make different methods for the two or else have this method check both to see which one is non-null. Comments from Reviewable |
|
Great! I have my fourth PR (load reporting service) ready now. But it's based on all the commit history from the previous PRs so it has a lot of noise. I will publish that one after this one is merged. Review status: all files reviewed, 3 unresolved discussions (waiting on @markdroth, @dgquintas, and @summerxyt) src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 105 at r4 (raw file): Previously, markdroth (Mark D. Roth) wrote…
Got it! src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 93 at r6 (raw file): Previously, markdroth (Mark D. Roth) wrote…
Sorry about repeatedly forgetting this! Upon further thought, I removed this struct, because we only use it in one place. src/core/ext/filters/load_reporting/server_load_reporting_filter.cc, line 95 at r6 (raw file): Previously, markdroth (Mark D. Roth) wrote…
Yeah, this doesn't seem straightforward enough. I have removed the whole struct. src/cpp/common/channel_filter.h, line 210 at r6 (raw file): Previously, markdroth (Mark D. Roth) wrote…
Done. I had this method check both. Comments from Reviewable |
3656565 to
6fef9fa
Compare
|
|
6fef9fa to
63163e1
Compare
|
|
63163e1 to
2856420
Compare
|
|
|
|
2856420 to
f5f1d57
Compare
|
|
|
|
I just removed the old |
| grpc_sockaddr* addr = reinterpret_cast<grpc_sockaddr*>(resolved_address.addr); | ||
| if (addr->sa_family == GRPC_AF_INET) { | ||
| grpc_sockaddr_in* addr4 = reinterpret_cast<grpc_sockaddr_in*>(addr); | ||
| gpr_asprintf(client_ip_string, "%08x", grpc_ntohl(addr4->sin_addr.s_addr)); |
There was a problem hiding this comment.
I added grpc_ntohl here after getting approval.
Looks like Reviewable is keeping all the history.
|
Green, of course 😁 . |
Based on #15196.
I refactored the internal implementation a little bit according to my understanding.
Eyeball checked the code several times. Currently I don't see any obvious error. I will test this in an end-to-end test.
This change is