Regarding behaviour during RollingUpgrade; I created a draft PR with this change to test the feasibility and see what problems, if any, would be caused by tests assuming the default setting to be true. After fixing two DUnit tests that were not explicitly setting the value of conserve-sockets to true, no test failures were observed. I also ran a large suite of proprietary tests that include rolling upgrade and observed no problems there. This doesn't mean that there would definitely be no problems caused by this change, but I can at least say that none of the testing we currently have showed any problems. ________________________________ From: Anthony Baker <bak...@vmware.com> Sent: Friday, November 20, 2020 8:52 AM To: dev@geode.apache.org <dev@geode.apache.org> Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false
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%7Cdoevans%40vmware.com%7C5707a5b4d38c451cf58908d88d74ce81%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637414880110757318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oKeeQ5Z6DPJAsQRUoZalfyahVRrmVq47CjYsFCKMios%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 >> >
