-
Notifications
You must be signed in to change notification settings - Fork 36
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
Proper resource cleanup for expired connections #1445
Comments
Hi @BenAgai, |
Hi @glazychev-art , |
@glazychev-art I'm reusing this thread as I have some questions about the timeout chain element which are unclear to me: |
@or-adar So, for example, if you set NSM_MAX_TOKEN_LIFETIME=1m only for NSC, then NSMgr calls Close after 1m (if refreshes do not take place regularly). Other components (forwarders, passthrough, NSEs) will also receive this Close from the NSMgr, but not from its timeout element (because they use NSM_MAX_TOKEN_LIFETIME=10m). For the normal case, this is sufficient. Some questions may arise in the case of healing. |
@glazychev-art appreciate the response! |
Yes, that's right |
Hi,
I wanted to ask a question regarding cleanup of expired connections made from an NSC to NSE.
Assuming NSC successfully established connection to an NSE.
If the NSC runs on a pod that got terminated without the NSC initiating close flow, we will have leak across the data path for that connection.
Is there any built in mechanism the recover from such scenario? (for example expiration on a connection that is renewed every time refresh occurs, and once the connection is expired a close flow is initiated for it).
I encountered the following links that looks relevant, but wasn’t sure:
networkservicemesh/deployments-k8s#8882
#1439
#1440
I will be glad to know if the issue is resolved and how, or whether should I implement such mechanism.
Thanks!
The text was updated successfully, but these errors were encountered: