1) Conserve-socket will only impact p2p connection. If set to false, that mean
the p2p connections between 2 servers can be created on request, as many as
needed.
2) currently the default setting is true (I don't remember when did we change
it from false to true)
3) For rollingUpgrade, unfortunately, if server1 is set to true and server2 is
set to false, our server start-up will not check the mismatch automatically so
far. We have to add some coding to prevent a server with different setting to
join. And I don't know in current mixed setting environment, what will be the
behavior. It could be an interesting dunit test scenario.
Regards
Gester
On 11/20/20, 8:53 AM, "Anthony Baker" <bak...@vmware.com> wrote:
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%7Czhouxh%40vmware.com%7Cc05dc303ad1342d8d06c08d88d74d3d6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637414880207409532%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kjRZ8dHZRi82x0tVsITBOca1T%2FIYPllZMLfUOTUxED4%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
>>
>
