Aurora Twinkle

Hi, Everyone! @lhotari @codelipenghui @asafm @liangyepianzhou @dao-jun @poorbarcode @Technoboy- I have sent a voting email for PIP-359: https://lists.apache.org/thread/oo3jdvq3b6bv6p4n7x7sdvypw4gp6hpk Thanks!

> One possible idea for avoiding cluttering the builder interfaces with more and more configuration options would be to support some type of extension pattern. > > In this case,...

@liangyepianzhou I have fixed all your comments, PTAL, thanks

> The general design is problematic since the health checking will keep running and creating TCP/IP connections that are immediately closed. This will cause additional load in the overall system,...

> [@AuroraTwinkle](https://github.com/AuroraTwinkle) I see the referenced discussion [#22933](https://github.com/apache/pulsar/discussions/22933). That's a good problem description. I think it's a bug when the next available serviceUrl isn't attempted. That's the whole point of...

> [@AuroraTwinkle](https://github.com/AuroraTwinkle) I see the referenced discussion [#22933](https://github.com/apache/pulsar/discussions/22933). That's a good problem description. I think it's a bug when the next available serviceUrl isn't attempted. That's the whole point of...

> > By analyzing the source code, we found > > that by default, all consumer instances created from the same PulsarClient > > will share a thread pool to...

> This isn't directly related to this feature request, but I thought that it might be useful to share. > > There's "PIP-234: Support using shared thread pool across multiple...

> I added some further comments to simplify MessageListenerExecutor. The lifecycle is managed by the application that provides the instance and that's why there shouldn't be any details of the...

> Thanks for this proposal @AuroraTwinkle . I believe that this will be a very useful addition to the Pulsar client. > > There are certain details of the Message...