Handle (and test) short call deadlines#9019
Conversation
| grpc_end2end_test_fixture f, size_t num_ops) { | ||
| grpc_call *c; | ||
| gpr_timespec deadline = gpr_inf_past(GPR_CLOCK_REALTIME); | ||
| gpr_timespec deadline = gpr_time_add(gpr_now(GPR_CLOCK_MONOTONIC), |
There was a problem hiding this comment.
Why not leave it as is since there is a new test covering the short deadline?
There was a problem hiding this comment.
oh woops. this file shouldn't have any changes. It's the one I used as the basis for the new one. I'll revert.
| @@ -0,0 +1,200 @@ | |||
| /* | |||
| * | |||
| * Copyright 2015, Google Inc. | |||
There was a problem hiding this comment.
We aren't changing those things anymore I think. Perhaps for new files we are? Hmm
| test_invoke_short_deadline_request(config, i, 5); | ||
| test_invoke_short_deadline_request(config, i, 10); | ||
| test_invoke_short_deadline_request(config, i, 15); | ||
| test_invoke_short_deadline_request(config, i, 30); |
There was a problem hiding this comment.
Is there anything to guarantee the rpc will fail with deadline exceeded (rather than succeed)?
There was a problem hiding this comment.
Ah, very good point... I'll make some changes so that the server side delays long enough.
There was a problem hiding this comment.
In fact, the test as-is will always time out, as there's no server-side logic present. I'll however add some, with the pertinent delay as mentioned, to make it explicit.
dgquintas
changed the title
dgquintas
force-pushed
the
short_deadlines
branch
from
01bfa7e to
9460166
Compare
3 participants
We had tests for a negative deadline. This new test uses very short deadlines instead (0-30 ms). The inspiration for this test comes from the Python issue #8389
This triggers the following failures:
A core reproduction of Python's insecure_interop_test_InsecureInteropTest fails often. #8389 (log). This is due to the error created in https://github.com/grpc/grpc/blob/master/src/core/ext/client_channel/client_channel.c#L686. The failure rate is 0.5%-1%. This is fixed by the changes to
client_channel.cin this same PR.A new secure handshake failure for SSL (log, another log). See SEGV during handshake when using very short deadline in client #9039. The failure rate is 0.5%-1%Fixed by Address comments from #8913. Also make changes needed for import. #8979