-
Notifications
You must be signed in to change notification settings - Fork 45
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
Close function doesn't actually close everything #191
Comments
It looks to me like this is probably a very long-standing problem with the implementation of The obvious solution would be to force a close of the connection from the client side, but I've been having trouble finding a workable way to do this— urllib3's |
We tried |
@agitelzon Hmm— that's unexpected, so maybe there is something else going on. We're continuing to investigate. |
Can you tell me exactly how many excess threads you are seeing? |
Also— I missed one detail in your original post that I should have commented on. You said:
That is not the documented behavior of
In other words, if you only want the client to be created once, and the configuration has not changed, you should not be calling |
Every time a new job would run in the code, we'd see 11 new threads created, 9 threads shutdown, and 2 threads would stick around forever. The next time a job would run, again 11 new, 9 closed, 2 left over. This would keep happening until the application ran out of threads in the system.
For now, our workaround was this block of code at the beginning of the try:
if ldclient.get().is_initialized():
logger.info("LAUNCHDARKLY already initialized")
return
except Exception as e:
logger.info("LAUNCHDARKLY not initialized yet. Setting config...")
pass |
Thanks. If it's 5 threads, then my original guess about what was going on was wrong, but that does give us a clue as to what else to look into. |
Sorry if this is a silly question, but... in the first code excerpt you posted, is it for sure that the |
Please take a look at my post again. I went back through our logs and got an accurate count and updated my post.
We went through a few iterations with testing the block of code and putting in print statements. I just grabbed a simplified version to post here. At first, we had the I could update the sample code with more statements if that would be helpful. |
skip tests that use a self-signed TLS cert in Python 3.7
Is this still being looked into? Looks like the SDK still has this issue where closing the LD client won't close the background stream. |
Yes, we are currently in discussions with the urllib3 developers regarding this issue. We are working with them to extend some functionality to address this issue. We will let you know as soon as we have this resolved! |
Is this a support request?
Support Ticket #31907
Describe the bug
We are running a python flask app on a set of linux servers and in an AWS lambda. In our app, we create a
ldclient
instance and try toclose()
it when we are done. Theldclient.get().close()
function call didn't close all threads. The left over threads pile up and over time hit the system thread limit, because the application process is still running and is called on a new task. We start getting an error ofRuntimeError: can't start new thread
In short, the bug is that the
close()
function didn't close all threads. Ifset_config
get's called a 2nd time, as documented, a newldclient
instance is created, the old one never completely goes away.To reproduce
Expected behavior
Ultimately, I expected the function
ldclient.get().close()
to close all threads and release allldclient
objects. I would expect my nextldclient.get().is_initialized()
to be false because I closedldclient
so it should be in a state where I have to callset_config
I expected
ldclient.set_config(ld_config)
to be smart enough to only create new instances if there doesn't exist an active instance or if the config values changed from the previous call. I know thatldclient.get()
enforces the singleton pattern, then I would expect `ldclient.set_config() to as well.Maybe there should be something like a
get_config
function to allow me to verify that the settings in code are the same as the active config and then I could re-use the existingldclient
instead of creating a new one.Logs
SDK version
We updated to version 7.5.1 and still saw this error. We tried v8.0.0 as well, same issue.
Language version, developer tools
Python 3.7
OS/platform
Docker container running
python:3.7-slim
and Ubuntu 20.04Additional context
The text was updated successfully, but these errors were encountered: