This lesson is locked. Login or Subscribe for more access!

Setting Deadlines in gRPC

Duration: 8 mins

It's important to ensure that requests do not run too long. Learn how to manage that here,

Instructor

Chris Shepherd

Share with a friend!

Transcript

Hey folks, so in this video we're going to look at how to configure deadlines on a gRPC client. Deadlines can be used to specify a point in time past when the client is unwilling to wait for a response from the server. This is important in building robust distributed systems because it means there's no blockages basically on the client or the server side and it means we're not using unnecessary resources as well.

So to do this we're going to add another RPC and for this we'll create a long running RPC. Just to demonstrate what this would look like on the client side, this RPC will be really simple - it'll basically take no request and return a response, but inside it we'll add a sleep just so we can see what happens when the server takes longer than the client is willing to wait.

Let's start out by adding our request and response, add our RPC, and generate the code. Then in our server we can implement it. So we've got our signature and now what we'll do is add a select statement in here and we will add a time.Tick with a set duration of 5 seconds, and after that we'll just add a simple log to say "finish".

The other thing we'd want to do in a situation where we might have an RPC that could take a long time is listen to the context signals. In this case we can listen to when the context is done and gracefully handle that error as well. This is important because if a client does hang up and ends or cancels the request, we would want to make sure that we stop processing the rest of that request that's already in flight.

In this example we won't do too much, but in a real world scenario you might have a database query, you might be doing inserts, you might be modifying data - you would want to stop and cancel the request gracefully instead of handling all those or doing all that afterwards. So here we'll listen to the done channel on the context, and then add a log to say "context cancelled" and return the error as well.

Now let's implement the client side. We'll call this deadline client, and to create a deadline on the client side, what we do is use the context.WithTimeout function and pass in a context that has a timeout when we make the call. We'll just pass an empty context as the parent and set a deadline of one second for now. Then, because our RPC will take five seconds to execute on the server side, we know this should time out. We'll defer the cancel function as well just to make sure the context is cancelled correctly.

We'll then do the usual things: first dial our connection and handle the error, initialize our client, then call our long running RPC and pass in the context that has the deadline. We'll log our error if there is one, otherwise we'll log "RPC call successfully made".

Let's try it out. We'll start by running the server, and now let's run our client and see what happens. As you can see, the client has received a "deadline exceeded" response back from the server because it cancelled the request. On the server side you can see that we got a "context cancelled" log - that was the log that we added here that cancelled the context.

One thing that's worth calling out is that here we didn't add any specific status to be returned; we just returned an error and so this would actually return an internal error, an internal status code. But because the client hung up the request before this, it wouldn't have received the response from the server - it would have just returned a deadline exceeded like we see here.

Just to prove that this would work if this was longer, we'll set this to 10 seconds now and this request should succeed because we're only waiting five seconds here instead. Let's try running it again. As you can see the server waited five seconds before returning a successful response and then the client received that response back as expected.

That's how simple it is to add custom deadlines onto your RPC calls on the client side. So I hope you found this interesting and I'll see you in the next video.