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

using fluent-logger-python with eventlet #183

Open
jshen28 opened this issue Jan 4, 2022 · 5 comments
Open

using fluent-logger-python with eventlet #183

jshen28 opened this issue Jan 4, 2022 · 5 comments

Comments

@jshen28
Copy link

jshen28 commented Jan 4, 2022

Hello,

I saw a surprising memory usage growth (see this issue). But when I remove monkey_patch looks like memory usage back to normal. Does fluent-logger-python compatible with eventlet?

@arcivanov
Copy link
Member

I don't know about eventlet, but I have been using it with gevent in production for about 4 years now with no problems.

@jshen28
Copy link
Author

jshen28 commented Jan 5, 2022

I saw fluent-logger uses threading.Local to store last errors, but does it make sense when it is running in an eventlet? I found, although it could be wrong observation, by removing threading.local, memory usage could be surprisingly reduced.

@arcivanov
Copy link
Member

The question is how does eventlet monkey-patch the threading.local if at all? You'll also see that we're using threading.Lock.
If eventlet is leaking memory through threading.local because it didn't monkey it correctly or if you're leaking eventlets that are not being garbage collected and thus retain local state, then there is not much Fluent logger can do about it, sorry.

@jshen28
Copy link
Author

jshen28 commented Jan 6, 2022

I understand, but I am still interested why last_error is stored and how can I take advantage of it. Because I am afraid this may not be easy to solve for eventlet, so if last_error is not used, I am thinking to fork the repo and maintaining a custom version...

@arcivanov
Copy link
Member

The reason for a thread local last error is because the same sender is global, can be shared by multiple threads as it's stateless, except for last error. Furthermore, the same behavior in AsyncSender allows the last error to be attributed to the invoking thread. It's not the best design but it's been there for a long time. Judging by eventlet/eventlet#741, it has been confirmed to be an eventlet bug.

I am thinking to fork the repo and maintaining a custom version...

https://www.youtube.com/watch?v=BvK6KsLkPUs

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

No branches or pull requests

2 participants