Zac Bentley
Zac Bentley
@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...
I think that still may result in issues, though. What if the library-global logger factory is configured to wrap a logger object whose lifecycle is not bound to the library--like...
To double down, I think the statement @merlimat made [here](https://github.com/apache/pulsar/issues/6463#issuecomment-910782962): > you're expected to keep 1 single instance of C++ Pulsar client for the duration of your application is not...
The following issues were all observed in response to similar testing: https://github.com/apache/pulsar-client-cpp/issues/86 https://github.com/apache/pulsar/issues/12556 https://github.com/apache/pulsar/issues/12555 https://github.com/apache/pulsar/issues/12554 https://github.com/apache/pulsar/issues/12553 https://github.com/apache/pulsar/issues/12552 https://github.com/apache/pulsar/issues/12551 The condition that caused these issues to occur appears to be interaction...
This is reproducible on 2.9.1, though I'm not sure if the underlying cause is the same as it was before. It's possible that one or more issues preventing immediate consumer-connect...
Big +1 to documenting the invariants that Tokio provides (or does not provide) in the presence of code that `fork(2)`s without `exec`ing. If there are no configurations of Tokio whatsoever...
> Fork is only supported in the following two cases: > > 1. The call to `fork` happens before the parent process uses Tokio in any way. > > 2....
Interesting. Can those global PID registries/self-pipes/SIGCHLD handlers be reset in any way? Are they reset "by coincidence" when a new Runtime is constructed? Are they cleared by runtime shutdown? Avoiding...
Understood. If I draft one, would you review a doc PR summarizing what you've indicated in this discussion, or do you think this issue thread is sufficient?
+1 to merging them; I think many packages like to move things between "submodule" and "subpackages" as an internal implementation detail (e.g. when a `submodule.py` grows so much support code...