-
Notifications
You must be signed in to change notification settings - Fork 221
HTTPClient not thread safe #144
Comments
seems to be related to the object session retrieved from the requests |
@jkhelil you are correct in assessing the root cause of this issue to be the request session implementation as this is what the standard consul agent's From the library's perspective, we can investigate alternatives or alternatives (feel free to propose a change or even better submit a PR); however I do feel think this is not a priority at the moment as this is a 10% case from what I can tell. |
I think it's overkill for If someone sees this and has interest, a PR would be very appreciated! |
Err...depends on if you would like to share sessions across requests and such. I could definitely see a use case for that. It also makes handling https easier IMO. That being said, if you want to go the |
I think I am hitting this problem when this library is used as a backend for Celery job results, as reported here. I see that what @cablehead suggested is a version of std.py that does its own session management rather than using the not-thread-safe session management in requests. Would a patch that uses urllib3 instead of requests be acceptable? That at least keeps connection pooling etc in play, rather than either a naive implementation using a standard library or a potentially buggy homebrew? P.S. I note from Stackoverflow that urllib is not threadsafe either. |
I want to use consul python module in a multiprocessing context : I need to execute x process and each of them is fetching node from consul with are advertising a special service, with special tag
To give you an idea, the code is almost this
I was printing in base.py the result of the request and there was wrong results, I add this to service method of class Health
the was mixed results
let say for tag1, it returns result for tag2
The text was updated successfully, but these errors were encountered: