-
Notifications
You must be signed in to change notification settings - Fork 10.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Core-supported context propagation #2750
Conversation
@@ -349,6 +349,15 @@ typedef struct grpc_op { | |||
} data; | |||
} grpc_op; | |||
|
|||
#define GRPC_INHERIT_DEADLINE 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
INHERIT => PROPAGATE maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that better... done.
I took a brief look and it should be fairly easy to use in C#. |
Conflicts: src/core/surface/channel.c
Conflicts: src/core/surface/channel.c
@@ -351,6 +351,19 @@ typedef struct grpc_op { | |||
} data; | |||
} grpc_op; | |||
|
|||
/* Propagation bits: this can be bitwise or-ed to form propagation_mask for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about auth context? Is that propagatable as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah... I wanted to talk to @jboeuf before I went ahead and added it - and I didn't get a chance yet (fallout from late-on-a-Friday-afternoon-decision-making-in-my-cubicle).
/** Propagate deadline */ | ||
#define GRPC_PROPAGATE_DEADLINE ((gpr_uint32)1) | ||
/** Propagate census context */ | ||
#define GRPC_PROPAGATE_CENSUS_CONTEXT ((gpr_uint32)2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This flag is somewhat redundant with the census state, as reflected in the return value from census_enabled() - this is what I was intending to use as a signal for whether we should do context propagation or not. We can certainly have both signals, but it could be confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
census_enabled is global. What if I want to make one RPC without tracing propagation (but perhaps with deadline propagation?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(This API is covering the grpc_call_set_census_context equivalent API)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You asked: What if I want to make one RPC without tracing propagation (but perhaps with deadline propagation?)
Good question. This would seem to be the best way of doing this (via updating the trace_mask when we start the operation). It raises another issue though, in that we use the census context for more than just tracing - what if I want to disable tracing, but keep stats collection enabled for this request? There are probably a couple of options here:
- Use the GRPC_PROPAGATE_CENSUS_CONTEXT flag to {en/dis}able all features of census that require propagation.
- Explicitly state that the GRPC_PROPAGATE_CENSUS_CONTEXT flag can only be used to disable tracing (leaving other census features that require propagation untouched).
- Add GRPC_PROPAGATE_CENSUS_CONTEXT_X flags for the other census features (RPC stats + CPU accounting) that are done per-context.
3 would be my preference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we find a half-way point perhaps?
GRPC_PROPAGATE_STATS
GRPC_PROPAGATE_TRACING
On Mon, Aug 3, 2015 at 9:14 AM Alistair Veitch notifications@github.com
wrote:
In include/grpc/grpc.h
#2750 (comment):@@ -351,6 +351,23 @@ typedef struct grpc_op {
} data;
} grpc_op;+/* Propagation bits: this can be bitwise or-ed to form propagation_mask for
- * grpc_call /
+/* Propagate deadline /
+#define GRPC_PROPAGATE_DEADLINE ((gpr_uint32)1)
+/* Propagate census context */
+#define GRPC_PROPAGATE_CENSUS_CONTEXT ((gpr_uint32)2)You asked: What if I want to make one RPC without tracing propagation (but
perhaps with deadline propagation?)Good question. This would seem to be the best way of doing this (via
updating the trace_mask when we start the operation). It raises another
issue though, in that we use the census context for more than just tracing
- what if I want to disable tracing, but keep stats collection enabled for
this request? There are probably a couple of options here:- Use the GRPC_PROPAGATE_CENSUS_CONTEXT flag to {en/dis}able all features
of census that require propagation.- Explicitly state that the GRPC_PROPAGATE_CENSUS_CONTEXT flag can only
be used to disable tracing (leaving other census features that require
propagation untouched).- Add GRPC_PROPAGATE_CENSUS_CONTEXT_X flags for the other census features
(RPC stats + CPU accounting) that are done per-context.3 would be my preference.
—
Reply to this email directly or view it on GitHub
https://github.com/grpc/grpc/pull/2750/files#r36101297.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM.
Could we find a half-way point perhaps?
GRPC_PROPAGATE_STATS
GRPC_PROPAGATE_TRACING
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't suppose you'd want to send me a PR against this one implementing
it? :)
On Mon, Aug 3, 2015 at 9:36 AM Alistair Veitch notifications@github.com
wrote:
In include/grpc/grpc.h
#2750 (comment):@@ -351,6 +351,23 @@ typedef struct grpc_op {
} data;
} grpc_op;+/* Propagation bits: this can be bitwise or-ed to form propagation_mask for
- * grpc_call /
+/* Propagate deadline /
+#define GRPC_PROPAGATE_DEADLINE ((gpr_uint32)1)
+/* Propagate census context */
+#define GRPC_PROPAGATE_CENSUS_CONTEXT ((gpr_uint32)2)SGTM.
Could we find a half-way point perhaps?
GRPC_PROPAGATE_STATS
GRPC_PROPAGATE_TRACING—
Reply to this email directly or view it on GitHub
https://github.com/grpc/grpc/pull/2750/files#r36103509.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't suppose you'd want to send me a PR against this one implementing it? :)
I can - but I think it will have to wait till we get #2668 figured out to do it "right". Which reminds me, I need to go and update that PR...
Currently the oauth2 variant of these tests is disabled. Will work with @jboeuf to figure out how to turn them on.
Added a test suite to this for the core library. Now most end2end tests have a variant that proxies calls and propagates context using this API. |
This is ready for review. |
include/ and src/python/ changes LGTM. |
/** Propagate deadline */ | ||
#define GRPC_PROPAGATE_DEADLINE ((gpr_uint32)1) | ||
/** Propagate census context */ | ||
#define GRPC_PROPAGATE_STATS_CONTEXT ((gpr_uint32)2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we're using the census name everywhere else, does it make sense to rename these similar to GRPC_PROPAGATE_CENSUS_STATS_CONTEXT? (I don't mind either way myself, just think of future readers of the code)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Mind adding |
One of these days I'll commit that I need to include '*.m' in global search replaces to memory... done. |
LG to me. |
propagation. Doing so gives flexibility in the future to define new | ||
propagation types that are default inherited or not. */ | ||
#define GRPC_PROPAGATE_DEFAULTS \ | ||
((gpr_uint32)((0xffff | GRPC_PROPAGATE_DEADLINE | \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we do the | GRPC_PROPAGATE_X
again? Does it always end up to 0xffff?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't change the result, but I wanted to explicit:
- the bits that default to on
- and what they mean in terms of what gets propagated
Green enough I think |
Core-supported context propagation
@nathanielmanistaatgoogle @murgatroid99 @soltanmm @tbetbetbe @jcanizales @jtattermusch @a-veitch after some discussion today with wrapped language folks we thought we'd try implementing context propagation directly in core.
Fixes #2747