Linkerd not closing connection after RequestAuthorizer rejected a request and did not call service


I am looking for help with RequestAuthorizers.

I have a custom RequestAuthorizer configured.
Now I have realized that, when I make a HTTP call to Linkerd, a connection to the destination is already established before the RequestAuthorizer is called.

When the request is rejected by the RequestAuthorizer this connection is not closed but stays open.
Rejecting the request means that the RequestAuthorizer returns a fulfilled Response Future without calling the service.

If I make another call now that is not rejected by the RequestAuthorizer, this connection is not reused but a new connection is established, even if I configure a client connectionPool with maxSize 1. (Hopefully I did that correctly)

As my test backend only supports a single connection (python’s SimpleHTTPServer) the whole setup is basically dead.

Is this the intended behavior?
Wouldn’t it make more sense to invoke the RequestAuthorizer before establishing a connection?


Hi @robertpanzer!

Linkerd does connection pooling which means that it will keep connections open for re-use. RequestAuthorizer operators on requests, not on connections. Therefore it can prevent a request from being sent, but not a connection from being established.

However, setting maxSize: 1 should limit Linkerd to only establishing one connection to the destination host. If this doesn’t seem to be the case, could you share your Linkerd config and the commands that you’re running to test this behavior so that we can investigate? Thanks!

Sorry for responding so late, I already thought I couldn’t reproduce the problem, but I think I could narrow it down now.

It seems to be related to multiple client names resolving to the same address.
That means I have name1 resolving to address1 and name2 also resolving to address1.

Now if a RequestAuthorizer rejects a request for name1 a connection to address1 is still open, which makes sense, because the next request should simply reuse it.

If I try a second request now with name2 it looks like it doesn’t use the first connection but opens a new one.

This sounds logical to me and it would be great if somebody could confirm that this the expected behavior or not.
If not I think I could provide a small example showing this behavior.


Hi @robertpanzer!

What you describe is the expected behavior. Each client maintains its own connection pool and connections are not shared between clients.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.