Question: how would this work with a rolling upgrade? If the user did not set this property and we changed the default I believe that we would prevent the upgraded member from rejoining the cluster.
Of course the user could explicitly set this property as you point out. Anthony > On Nov 20, 2020, at 8:49 AM, Donal Evans <doev...@vmware.com> wrote: > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fghei36&data=04%7C01%7Cbakera%40vmware.com%7C0f9b5f57066447a0141c08d88d744a67%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637414877890840409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V65jEFWBflK8CWzFgxuFwQBD%2BV2BDlOlPa%2FtLR2N3eY%3D&reserved=0> > > ________________________________ > 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 >> >
