[GitHub] [pulsar] zbentley commented on issue #11845: [2.8.0] Python client instances emit logs for every client instance ever constructed with a `logger` argument

[GitBox <gi...@apache.org>]

zbentley commented on issue #11845:
URL: https://github.com/apache/pulsar/issues/11845#issuecomment-1181903154

   @BewareMyPower that's pretty unusual and bad behavior at least in the Python ecosystem. Client objects aren't singletons; they shouldn't store state once discarded. Most production code that uses clients for anything (databases, brokers, you name it) supports the total destruction and then reconnection/reconfiguration of clients. 
   
   That includes logging behavior; especially because there are some really weird interactions between Python clients with the logger set and the Python runtime itself (https://github.com/apache/pulsar/issues/16527), I think it's important to make sure that when a `Client` object is garbage collected in Python, all state is reset to what it was before that `Client` was created. That includes:
   - Logger settings (i.e. no global singletons in c++; everything should be scoped--the Pulsar client shouldn't act like a Boost _application_ with const/static loggers; it should act like a boost _library_ that can be loaded/unloaded/reset).
   - Threads--none should leak.
   - Filehandles.
   
   In general, the client shouldn't use process-global state; just instance-global state. Instances are not necesarily long-lived or singletons.
   
   For example, our production use case maintains (and periodically disconnects/reconnects) a handful of clients to different brokers, each with different logging settings.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org