Open dhiaayachi opened 1 month ago
Thanks for reporting this issue.
It looks like you've identified a potential issue with the GetRemoteAdminClient
and GetRemoteFrontendClient
functions caching clients indefinitely, even after TLS certs are updated.
This behavior might lead to unexpected issues if the TLS certs are changed, as the clients might continue using the old, potentially invalid, certificates.
To work around this, you can consider the following:
GetRemoteAdminClient
and GetRemoteFrontendClient
functions again after updating the TLS certs. This will ensure that you're using the latest certificates.GetRemoteAdminClient
and GetRemoteFrontendClient
functions or using a different approach for managing the client connections.We are currently investigating this behavior and will update the documentation if a solution is found.
Thanks for reporting this.
The GetRemoteAdminClient
and GetRemoteFrontendClient
functions in client_bean.go
currently do cache admin and frontend clients. This means that if TLS certs are updated, the clients will continue to use the old certs until they are recreated.
A workaround for this is to manually recreate the clients after the TLS certs have been updated. You can do this by calling the functions again, or by using a different client library that doesn't cache the clients.
We are aware of this issue and are working on a solution.
For more information on this, see the issue.
Expected Behavior
When TLS certs are updated, properly propagate the cert changes to admin / frontend / matching / history clients
Actual Behavior
Seems that GetRemoteAdminClient GetRemoteFrontendClient both functions will cache created admin / frontend client forever, even after TLS certs are updated