Skip to content
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

Only store channel if use_cached_channel is true #387

Merged
merged 3 commits into from
Apr 17, 2024

Conversation

HennerM
Copy link
Contributor

@HennerM HennerM commented Sep 4, 2023

The gRPC client exposes a parameter that disables reusing a cached channel: use_cached_channel.
Setting this to false doesn't stop the channel (and mock) from being inserted to the internal channel cache. The problem with it being inserted to the map means the channel will only get destroyed once it's being replaced by another channel.

In our case we want the channel (and associated connection) to be closed as soon as the client using it is getting destroyed though, meaning we don't want to reuse the channel at all. I believe this is also consistent with the description for use_cached_channel:

use_cached_channel If false, a new channel is created for each
/// new client instance. When true, re-use old channels from cache for new
/// client instances. The default value is true

@HennerM
Copy link
Contributor Author

HennerM commented Jan 6, 2024

@Tabrizian would you mind having a look at this? We have to keep an internal fork because of this behaviour. I already have the CLA signed (for my organisation Speechmatics)

@Tabrizian Tabrizian requested a review from debermudez January 13, 2024 00:47
@Tabrizian
Copy link
Member

@debermudez is this something that you could help with reviewing?

@debermudez
Copy link
Contributor

Yea. I will make a ticket to track this and look at it next week.
On a surface level, it seems straightforward enough ( I say hoping not to curse my future self ).

@debermudez
Copy link
Contributor

@HennerM I have not forgotten about this, but was unfortunately sidetracked. I am trying to review this today.
In the meantime, have you signed the CLA: https://github.com/triton-inference-server/server/blob/main/CONTRIBUTING.md#contributor-license-agreement-cla
We need a signed CLA to accept any code contributions.

@debermudez
Copy link
Contributor

I completely missed your second message. Nevermind my ask.

@debermudez debermudez mentioned this pull request Feb 2, 2024
@debermudez
Copy link
Contributor

@HennerM Wanted to give you a quick update. This is actively being tested via this PR: #465
If it passes, we should be able to get this merged shortly after.

@HennerM
Copy link
Contributor Author

HennerM commented Mar 30, 2024

@debermudez Thanks, is this still being worked at?

@aancel
Copy link

aancel commented Apr 8, 2024

I'm also looking forward to having the changes proposed by @HennerM being integrated to this repo, as this is also a need we recently had ! 👍

@HennerM
Copy link
Contributor Author

HennerM commented Apr 10, 2024

@Tabrizian did this get lost?

@debermudez
Copy link
Contributor

Sorry no it did not get lost.
I got pulled off for something else.
I have handed this off to another team mate: @jbkyang-nvi

@jbkyang-nvi
Copy link
Contributor

Hello. Looking into this now. As an FYI, this will be added to the 24.05 release instead of 24.04 since it was not prioritized for this release.

@HennerM
Copy link
Contributor Author

HennerM commented Apr 11, 2024

Hello. Looking into this now. As an FYI, this will be added to the 24.05 release instead of 24.04 since it was not prioritized for this release.

Thanks! That's okay, we waited already some time, the one month is not going to make a big difference :)

@jbkyang-nvi
Copy link
Contributor

jbkyang-nvi commented Apr 17, 2024

Merging with #465 and tested with triton-inference-server/server#7123 after pre-commit passes

@jbkyang-nvi jbkyang-nvi merged commit 5d969a6 into triton-inference-server:main Apr 17, 2024
3 checks passed
jbkyang-nvi pushed a commit that referenced this pull request Apr 17, 2024
Adding testing to verify new use_cached_channel behavior.
To be merged after #387
Server test: triton-inference-server/server#7123
---------
Co-authored-by: Markus Hennerbichler <[email protected]>
Co-authored-by: Katherine Yang <[email protected]>
Co-authored-by: Katherine Yang <[email protected]>
jbkyang-nvi added a commit to triton-inference-server/server that referenced this pull request Apr 17, 2024
debermudez pushed a commit that referenced this pull request Apr 18, 2024
The gRPC client exposes a parameter that disables reusing a cached
channel: use_cached_channel. Setting this to false doesn't stop the
channel (and mock) from being inserted to the internal channel cache. 
The problem with it being inserted to the map means the channel will
only get destroyed once it's being replaced by another channel.

In our case we want the channel (and associated connection) to be closed
 as soon as the client using it is getting destroyed though, meaning we don't
 want to reuse the channel at all. I believe this is also consistent with the 
description for use_cached_channel:

If false, a new channel is created for each
new client instance. When true, re-use old channels from cache for new
client instances. The default value is true
debermudez added a commit that referenced this pull request Apr 18, 2024
Adding testing to verify new use_cached_channel behavior.
To be merged after #387
Server test: triton-inference-server/server#7123
---------
Co-authored-by: Markus Hennerbichler <[email protected]>
Co-authored-by: Katherine Yang <[email protected]>
Co-authored-by: Katherine Yang <[email protected]>
mc-nv pushed a commit that referenced this pull request Apr 18, 2024
The gRPC client exposes a parameter that disables reusing a cached
channel: use_cached_channel. Setting this to false doesn't stop the
channel (and mock) from being inserted to the internal channel cache. 
The problem with it being inserted to the map means the channel will
only get destroyed once it's being replaced by another channel.

In our case we want the channel (and associated connection) to be closed
 as soon as the client using it is getting destroyed though, meaning we don't
 want to reuse the channel at all. I believe this is also consistent with the 
description for use_cached_channel:

If false, a new channel is created for each
new client instance. When true, re-use old channels from cache for new
client instances. The default value is true
mc-nv pushed a commit that referenced this pull request Apr 18, 2024
Adding testing to verify new use_cached_channel behavior.
To be merged after #387
Server test: triton-inference-server/server#7123
---------
Co-authored-by: Markus Hennerbichler <[email protected]>
Co-authored-by: Katherine Yang <[email protected]>
Co-authored-by: Katherine Yang <[email protected]>
@HennerM
Copy link
Contributor Author

HennerM commented Apr 20, 2024

Thanks for getting this merged!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

5 participants