While I agree that the potential impact of having the setting changed out from a user may be high, the cost of addressing that change is very small. All users have to do is explicitly set the conserve-sockets value to true if they were previously using the default and they will be back to where they started with no change in behaviour or resource requirements. This could be as simple as adding a single line to a properties file, which seems like a pretty small inconvenience.
Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Anthony Baker <bak...@vmware.com> Sent: Thursday, November 19, 2020 5:57:33 PM To: dev@geode.apache.org <dev@geode.apache.org> Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false 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 >
