lhotari commented on PR #23165: URL: https://github.com/apache/pulsar/pull/23165#issuecomment-2287016885
> > Just curious to know when it would be useful to tune this value for Pulsar. What is the purpose and background of this PR, is there a real reason behind this? > > The TCP backlog parameter is an OS-level configuration, if Pulsar doesn't set it, it will use OS config. > When many connections are trying to connect to the broker, some of them can be rejected by the TCP protocol. > Since it is an OS-level config, it's not easy to locate the problem if this situation happens. > > We ran into this problem in our customer's Pulsar cluster, their SO_BACKLOG was set to 128 on their OS, and we found many producers/consumers failed to connect to the broker(they have more than 50k consumers on 3 brokers). After analyzing the TCP packets, we found the problem. > > I wanted to hard-code the SO_BACKLOG to 1024, but a configuration item may be better. > > And if we explicitly declare this in Pulsar instead of using the SO_BACKLOG value which configured in `/proc/sys/net/core/somaxconn` file, it could be easier to locate the problem when we run into the same problem. Thanks for explaining the context @dao-jun -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
