I think there are many good reasons to flip the default value for this property. I do question whether requiring a user to allocate new hardware to support the changed resource requirements is appropriate for a minor version bump. In most cases I think that would come as an unwelcome surprise during the upgrade.
Anthony > On Nov 19, 2020, at 10:42 AM, Dan Smith <dasm...@vmware.com> wrote: > > Personally, this has caused enough grief in the past (both ways, actually!) > that I 'd say this is a major version change. > I agree with John. Either value of conserve-sockets can crash or hang your > system depending on your use case. > > If this was just a matter of slowing down or speeding up performance, I think > we could change it. But users that are impacted won't just see their system > slow down. It will crash or hang. Potentially only with production sized > workloads. > > With conserve-sockets=false every thread on the server creates its own > sockets to other servers. With N servers that's N sockets per thread. With > our default of a max of 800 threads for client connections and a 20 server > cluster you are looking at a worst case of 800 * 20 = 16K sending sockets per > server, with another 16K receiving sockets and 16K receiving threads. That's > before considering function execution threads, WAN receivers, and various > other executors we have on the server. Users with too many threads will hit > their file descriptor or thread limits. Or they will run out of memory for > thread stacks, socket buffers, etc. > > -Dan >
